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PREFACE 


This  system  programmer's  manual  covers  the  work  performed 
under  Air  Force  Contract  F33615-80-C-5155  (ICAM  Project  6201). 
This  contract  is  sponsored  by  the  Materials  Laboratory,  Air 
Force  Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio. 

It  vas  administered  under  the  technical  direction  of  Mr.  Gerald 
C.  Shumaker.  ICAM  Program  Manager,  Manufacturing  Technology 
Division,  through  Project  Manager,  Mr.  David  Judson.  The  Prime 
Contractor  vas  Production  Resources  Consulting  of  the  General 
Electric  Company,  Schenectady,  Mew  York,  under  the  direction  of 
Mr.  Allan  Rubenstein.  The  General  Electric  Project  Manager  vas 
Mr.  Myron  Hurlbut  of  Industrial  Automation  Systems  Department, 
Albany.  Mew  York. 

Certain  work  aimed  at  improving  Test  Bed  Technology  has 
been  performed  by  other  contracts  with  Project  6201  performing 
integrating  functions.  This  work  consisted  of  enhancements  to 
Test  Bed  software  and  establ ishment  and  operation  of  Test  Bed 
hardware  and  communications  for  developers  and  other  users. 
Documentation  relating  to  the  Test  Bed  from  all  of  these 
contractors  and  projects  have  been  integrated  under  Project  6201 
for  publication  and  treatment  as  an  integrated  set  of  documents. 
The  particular  contributors  to  each  document  are  noted  on  the 
Report  Documentation  Page  (DD1473).  A  listing  and  description 
of  the  entire  project  documentation  system  and  how  they  are 
related  is  contained  in  document  FTR620100001 ,  Pro ject ‘Overview . 

The  subcontractors  and  their  contributing  activities  were 
as  follows: 


TASK  4.2 

Subcontractors 

Boeing  Military  Aircraft 
Company  (BMAC) 

D.  Appleton  Company 
(DACOM) 


General  Dynamics/ 
Ft.  Worth 


Role 

Reviewer 


Responsible  for  IDEF  support, 
state-of-the-art  literature 
search 

Responsible  for  factory  view 
function  and  information 
models 
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Subcontractors  Role 

Illinois  Institute  of  Responsible  for  factory  view 

Technology  function  research  (IITRI) 

and  information  model 6  of 
small  and  medium-size  business 

North  American  Rockwell  Reviewer 

Northrop  Corporation  Responsible  for  factory  view 

function  and  information 
models 

Pritsker  and  Associates  Responsible  for  IDEF2  support 

SofTech  Responsible  for  IDEFO  support 


TASKS  4.3  -  4.9  (TEST  BED: 


Subcontractors 


Role 


Boeing  Military  Aircraft  Responsible  for  consultation  on 
Company  (BMAC)  applications  of  the  technology 

and  on  IBM  oomputer  technology. 


Computer  Technology  Assisted  in  the  areas  of 

Associates  (CTA)  communications  systems,  system 

design  and  integration 
methodology,  and  design  of  the 
Network  Transaction  Manager. 


Control  Data  Corporation  Responsible  for  the  Common  Data 
(CDC)  Model  (CDM)  implementation  and 

part  of  the  CDM  design  (shared 
with  DACOM). 


D.  Appleton  Company  Responsible  for  the  overall  CDM 

(DACOM)  Subystem  design  integration  and 

test  plan,  as  well  as  part  of 
the  design  of  the  CDM  (shared 
with  CDC).  DACOM  also 
developed  the  Integration 
Methodology  and  did  the  schema 
mappings  for  the  Application 
Subsystems . 
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Subcontractors 


Digital  Equipment 
Corporation  (DEC) 


McDonnell  Douglas 
Automation  Company 
(McAuto) 


On-Line  Software 
International  (OSI) 


Role 

Consulting  and  support  of  the 
performance  testing  and  on  DEC 
software  and  computer  systems 
operation. 

Responsible  for  the  support  and 
enhancements  to  the  Network 
Transaction  Manager  Subsystem 
during  1984/1985  period. 

Responsible  for  programming  the 
Communi cat ions  Subsystem  on  the 
IBM  and  for  consulting  on  the 
IBM. 


Rath  and  Strong  Systems 
Products  (RSSP)  (In  1985 
became  McCormack  8  Dodge) 


SofTeoh .  Inc . 


Software  Performance 
Engineering  (SPE) 


Structural  Dynamics 
Research  Corporation 
(SDRC) 


Responsible  for  assistance  in 
the  implementation  and  use  of 
the  MRP  II  package  (PIOS)  that 
they  supplied. 

Responsible  for  the  design  and 
implementation  of  the  Network 
Transaction  Manager  (NTM)  in 
1981/1984  period. 

Responsible  for  directing  the 
work  on  performance  evaluation 
and  analysis. 

Responsible  for  the  User 
Interface  and  Virtual  Terminal 
Interface  Subsystems. 


Subcontractors  and  other  prime  contractors  under  other 
projects  who  have  contributed  to  Test  Bed  Technology,  their 
contributing  activities  and  responsible  projects  are  as  follows: 


Subcontractors  Role 

General  Dynamics/  Responsible  for 

Ft.  North  factory  view 
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Contractors 

Boeing  Military 

A i rcraf t  Company 
(BMAC) 

ICAM  Proieot 

1701,  2201, 
2202 

Contributing  Activities 

Enhancements  for  IBM 

node  use.  Technology 
Transfer  to  Integrated 
Sheet  Metal  Center 

Cl SMC) 

Control  Data 
Corporation  (CDC) 

1502,  1701 

IISS  enhancements  to 
Common  Data  Model 

Processor  (CDMP) 

D.  Appleton  Company 
(DAOOM)  1 

1502 

IISS  enhancements  to 
Integration  Methodology 

General  Electric 

1502 

Operation  of  the  Test 

Bed  and  communications 
equipment . 

Hughes  Aircraft 

Company  (HAC) 

1701 

Test  Bed  enhancements 

Structural  Dynamics 
Research  Corporation 
CSDRC) 

1502,  1701, 
1703 

IISS  enhancements  to 

User  Interface/Virtual 
Terminal  Interface 
(UI/VTI) 

Systran 

1502 

Test  Bed  enhancements. 
Operation  of  Test  Bed. 
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SECTION  1 
INTRODUCTION 


This  NTH  System  Programmer ' s  Manual  is  offered  to  provide 
an  understanding  of  the  internal  structure  of  the  Network 
Transaction  Manager  ( NTM)  code.  To  place  the  code  in  its  proper 
context.  Section  2  provides  an  overview  of  the  Architecture  of 
the  NTM  and  the  major  components  within  that  architecture. 
Section  3  discusses  the  details  of  the  modules  within  each  of 
the  major  components.  Section  4  discusses  the  Data  Structures 
associated  with  the  major  components  along  with  a  discussion  of 
the  NTM  internal  tables.  Section  5  covers  those  aspects  of  the 
NTM  code  that  are  host  system  dependent. 
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SECT 10W  2 
SYSTEM  OVERVIEW 


2.1  The  HTM  Within  the  IISS  Architecture 

The  IISS  is  a  system  that  incorporates  heterogeneous  host 
aachines  into  a  network  to  provide  transaction  processing 
services  within  a  aanufacturing  environment.  Figure  2-1 
provides  the  conceptual  view  of  the  IISS  on  one  host  aachine;  in 
this  instance,  the  VAX.* 

The  basis  of  the  IISS  architecture  is  the  conoept  of  AP 
clusters.  An  AP  cluster  is  defined  as  a  highly  cohesive  group 
(one  or  aore)  of  Application  Processes  that  have  either  one  or 
no  Database  Manager  (and  by  extension,  database)  in  coaaon.  This 
concept  allows  for  the  isolation  of  application  functions  based 
upon  the  data  they  need  to  access.  The  IISS  components,  the 
User  Interface  (UI).  Communications  Handler  (COMM),  and  Common 
Data  Model  Request  Processor  (CDKRP)  are  seen  as  Application 
Processes  that  each  reside  on  a  distinct  AP  cluster. 

Mon- integrated  or  "Existing"  Applications  (applications  designed 
without  adherence  to  IISS  integration  rules)  may  also  reside  on 
separate  AP  clusters  in  aooordance  with  the  rule  that  they 
access  the  cluster's  common  database.  Integrated  or  "Mew" 
Applications  (applications  designed  and  written  in  accordance 
with  the  IISS  Integration  Rules)  will  either  reside  on  separate 
AP  clusters  or  be  added  to  existing  AP  clusters  depending  upon 
database(s)  they  need  to  access.  An  Application  Process  (AP) 
within  the  IISS  architecture  is  a  cohesive  unit  of  software  that 
can  be  initiated  as  a  unit  to  perform  some  function  or 
functions.  All  APs  within  the  IISS  are  treated  in  the  same 
manner  by  the  NTM. 

The  NTM  provides  the  common  operating  thread  for  each  AP 
cluster.  A  component  of  the  NTM  known  as  the  Message  Processing 
Unit  (MPU)  will  be  associated  with  each  AP  cluster  to  provide 
for  message  management,  process  management,  and  to  maintain  AP 
cluster  operability. 


♦VAX  is  a  trademark  of  the  Digital  Equipment  Corporation. 


2-1 


SUM620 142000 
1  Movenber  1985 


2-2 


Figure  2-1.  I1SS  Architecture  -  Conceptual  Model  on  VAX 
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Some  examples  of  APs  in  the  ZZSS  are:  User  Application 
Processes  such  as  an  MCMM  component  oapable  of  processing  a 
transaction;  and  ZZSS  components  such  as  the  User  Interface, 
Communication  Handler,  and  Common  Data  Hodel  Request  Processor. 
The  KTM's  ooncern  in  all  oases  is  to  provide  a  transparent 
logical  link  from  any  AP  to  any  other  AP  in  the  ZZSS  system. 

Each  AP  is  seen  by  the  NTH  as  a  stand-alone  unit  that  is  fully 
capable  of  performing  its  own  processing  and  normally 
terminating  itself. 

In  addition  to  the  MPU  component,  the  HTM  contains  the 
Monitor  Application  Process  and  the  HTM  system  and  table 
services.  These  three  components  work  together  to  provide 
system  start-up  and  shut-down  coordination,  system  monitoring, 
IISS  Operator  Interface,  and  message  processing  services  for  the 
APs. 


2.2  HTM  Components  -  Overview 
2.2.1  Monitor  Application  Process 

The  Monitor  Application  Prooess  (Monitor  AP)  is  the  HTM 
component  which  provides  a  central  oontrol  point  for  the  IISS 
environment  on  an  IISS  host  node.  Monitor  AP's  responsibilities 
Include  coordinating  IISS  start-up  and  shut-down,  monitoring 
IISS  operating  activity,  and  providing  an  interface  to  the  IISS 
operator . 

The  Monitor  AP  is  the  first  HTM  component  to  begin 
execution  when  the  IISS  is  started.  All  Application  Process 
Clusters  (APC's)  and  all  IISS  network  communications  are 
initiated  under  the  control  of  the  Monitor  AP.  Monitor  AP 
begins  execution  by  initializing  its  local  variables  and 
creating  and  initializing  the  host  global  HTM  tables.  It  then 
spawns  its  own  MPU  and  establishes  communications  with  it  via  a 
message  exchange  protocol.  With  the  complete  Monitor  APC 
active,  the  Monitor  AP  begins  requesting  the  initiation  of  host 
local  APC's.  Messages  are  sent  to  the  Monitor  APC  MPU  which 
Interprets  these  commands  and  spawns  the  requested  MPU.  Once 
all  local  APC's  have  been  started,  network  communications  are 
initiated.  Monitor  AP  accomplishes  this  by  first  requesting 
that  the  COMM  APC  MPU  initiate  the  appropriate  COMM  AP  and  then 
forwarding  a  "Start  Link"  message  to  the  COMM  AP. 

When  start-up  is  complete.  Monitor  AP  updates  the  system 
tables  and  sends  a  "Host  Active"  message  to  all  looal  MPU's 
indicating  that  normal  IISS  processing  may  begin. 
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The  process  described  above  is  currently  applicable  only 
to  the  “central"  node  (VAX).  A  "reeote"  (non-VAX)  host  has  a 
slightly  different  start-up  procedure  due  to  the  fact  that  the 
current  implementation  of  the  NTH  requires  remote  hosts  to  have 
an  active  link  to  the  central  node  to  run  in  the  XXSS 
environment.  This  is  based  on  an  architecture  where  the  CDM 
will  reside  on  only  one  (Central)  Node.  After  initiating  the 
Monitor  APC.  as  above,  the  remote  node  must  establish  a 
communication  link  to  the  central  node  before  continuing  with 
start-up.  This  will  enable  the  remote  node  to  access  the  CDM. 
The  remote  host's  Monitor  AP  initiates  its  COMM  APC  and  the 
appropriate  COMM  link  and  waits  for  a  response  from  the  central 
node  Monitor  AP  indicating  that  it  is  active.  Once  this  link 
has  been  established,  start-up  continues  as  described  above. 

With  the  IISS  started  and  in  a  stable  state.  Monitor  AP 
assumes  the  role  of  system  monitor  -  handling  system  error 
messages,  processing  operator  commands,  and  maintaining  the 
operability  of  the  IISS  environment.  The  Monitor  AP  accepts 
error  and  status  messages  from  system  components  for  display  on 
the  operator  console.  The  following  operator  commands  are 
supported  by  the  Monitor  AP: 

1.  Shut-down  IISS 

2.  Shut-down  APC 

3 .  Start  APC 

4.  Shut-down  COMM  Link 

5.  Start  COMM  Link 

6.  Cancel  IISS  shut-down 

7.  Display  System  Status 

8.  Display  Active  AP's 

9.  Enable  SIGERR  Messages 

10.  Disable  SIGERR  Messages 

11.  Select  Logging  Features 

12.  Start  New  Log  File 

Upon  receiving  the  Shut-down  IISS  command.  Monitor  begins 
coordinating  the  orderly  shut-down  of  the  IISS.  Prior  to 
actually  beginning  shut-down  processing.  Monitor  AP  notifies 
IISS  users  that  the  system  shut-down  is  pending  via  the  Ul  APC's 
MPU.  When  shut-down  begins,  the  non-component  APC's  are 
shut-down  first.  Network  communi cat ions  are  then  terminated 
followed  by  the  shut-down  of  the  component  APC's.  When  all 
other  NTM  components  are  shut-down.  Monitor  AP  request  the 
shut-down  of  its  MPU  and  then  end6  its  own  execution. 
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2.2.2  Message  Processing  Unit 

The  purpose  of  the  Message  Processing  Unit  (MPU)  of  the 
Network  Transaction  Manager  (NTM)  is  to  handle  couuni  cat  ions 
between  application  processes  on  the  ZZSS.  These  processes  are 
associated  with  a  cluster  with  each  cluster  having  its  own 
Message  Processing  Unit.  The  MPU  enables  its  application 
processes  to  communicate  with  and  initiate  other  application 
processes  on  the  cluster,  off  the  cluster,  and  off  host  via 
messages.  The  MPU  aonitors  its  AP's  activities  and  provides 
other  useful  features  (such  as  Message  Pairing,  tracking  an  AP's 
“children.1*  and  queuing  messages)  for  the  APs. 

The  Message  Processing  Unit  has  three  stages  of  operation 
— Start-up,  APC  Operation,  and  Shut-down.  The  Monitor 
Application  Process  (Monitor  AP)  initiates  the  first  instance  of 
an  MPU  (the  Monitor  MPU)  while  all  other  Message  Processing 
Units  are  initiated  by  the  Monitor  MPU. 

The  Start-up  stage  of  an  MPU  involves  getting  the  MPU's 
process  name  from  the  operating  system,  reading  the  start-up 
file  for  sysgen  data  and  creating  the  APC's  high  and  low 
priority  mailboxes.  The  MPU  then  sends  a  message  to  the  Monitor 
AP  requesting  the  status  of  the  tables  on  the  cluster  and  waits 
for  a  response  from  the  Monitor  AP.  If  the  response  does  not 
arrive  within  a  given  time,  the  MPU  will  send  an  “AP  cluster 
terminating'  message  to  the  Monitor  AP  and  will  proceed  to 
terminate.  Should  the  message  arrive,  the  MPU  will  populate  the 
tables  in  accordance  with  the  current  table  status.  The  MPU 
then  sends  an  “AP  cluster  alive”  message  to  the  Monitor  AP  and 
waits  for  final  start-up  instructions. 

Should  an  error  occur  during  the  ZZSS  start-up,  the 
Monitor  AP  will  instruct  each  Message  Processing  Unit  to 
terminate.  Zf  IZSS  start-up  is  successful,  the  Monitor  AP  will 
send  a  "  host  active"  message  to  signal  the  MPU  that  Start-up  is 
complete.  Zf  the  final  instruction  message  does  not  arrive 
within  a  given  time,  the  MPU  will  assume  an  error  has  occured 
and  begin  the  AP  cluster  termination  prooess  on  its  own. 

During  the  APC  Operations  phase,  the  MPU  is  available  to 
application  processes  on  its  APC.  The  AP’s  oan  communicate  with 
one  another  and  initiate  other  application  processes  by  sending 
messages  through  the  MPU.  The  MPU  processes  these  messages  in 
two  phases;  Manage  Message  and  Prooess  Message. 

The  Manage  Message  phase  authorises  the  message,  verifies 
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the  message  category,  assigns  a  serial  number  amd  completes  the 
message  header  for  messages  from  on  the  cluster.  If  the  message 
is  from  another  cluster.  Manage  Message  verifies  that  the 
message  arrived  at  the  correct  destination.  If  a  message  error 
occurs,  the  MPU  will  send  an  error  message  to  the  Souroe  AP.  If 
a  system  error  oocurs,  the  MPU  will  send  an  error  message  to  the 
Monitor  AP.  All  messages  are  currently  logged  in  the  Manage 
Message  phase.  The  type  of  processing  to  be  done  on  the  message 
is  also  determined  at  this  time.  Messages  destined  to  off-host 
AP's  are  sent  to  the  Communication  Handler  APC's  MPU;  messages 
destined  to  on-host  but  off -cluster  are  delivered  to  the 
off -cluster  MPU;  and  messages  destined  for  on-cluster  are 
processed  by  phase  two  of  APC  operations;  Manage  Process. 

Manage  Process  handles  each  message  destined  for  the  AP 
cluster  according  to  its  message  category  and  type .  Some 
messages  cause  the  initiation  of  other  application  processes  in 
the  IISS;  others  are  simply  delivered  to  the  Destination  AP. 

During  the  APC  Operations  phase,  a  timer  is  set  for  each 
MPU.  When  the  timer  goes  off,  a  checking  routine  is  invoked. 

The  checking  routine  looks  at  time  dependent  processes  such  as 
the  AP  initiation,  message  pairing,  and  message  queuing 
services.  Tables  and  queues  are  checked  for  messages  that  have 
timed  out,  AP's  that  have  completed  their  initiation  phase, 
messages  waiting  for  a  resource,  and  so  forth.  Each  entity  is 
handled  in  accordance  with  its  current  status.  As  an  example, 
the  Message  Pair  table  has  an  entry  for  each  message  that 
requires  a  response.  If  the  time-out  time  on  the  entry  has 
passed  (compared  to  the  system  time),  the  MPU  deletes  the  entry 
and  sends  a  "time-out  error’  message  to  the  Source  AP.  After 
completion  of  the  checking  routine,  the  timer  is  re- set. 

In  addition  to  handling  application  process  messages, 
each  MPU  has  a  high-priority  mailbox  from  which  it  reads  system 
command  messages  from  the  IISS  operator  via  the  Monitor  AP.  For 
example,  the  operator  may  request  a  list  of  all  active  APs  on 
the  MPU's  cluster.  The  system  command  message  that  requires  the 
MPU  to  go  into  it's  final  stage  of  operation  is  a  "Shut-down  AP 
Cluster"  message  from  the  operator  via  the  Monitor  AP. 

The  Shut-down  6tage  of  the  Message  Processing  Unit 
operates  in  a  similar  manner  to  the  APC  Operations  stage. 
Messages  are  still  processed  by  the  MPU.  However,  when  the  MPU 
receives  the  "Shut-down  APC"  message,  it  looks  at  each 
application  process  in  the  AP  Status  table  and,  according  to  the 
AP's  characteristic,  aborts  the  AP  or  Informs  it  that  it  must 
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shut  itself  down.  The  MPU  then  checks  its  mailboxes  for  a 
message  from  each  of  the  APs  that  were  told  to  shut-down.  Only 
AP  Status  messages  and  system  commands  from  the  Monitor  AP  are 
processed  normally  during  the  shut-down  phase.  All  other  types 
of  messages  may  be  logged  but  otherwise  ignored  by  the  MPU.  The 
MPU  systematically  checks  to  see  if  all  the  application 
processes  on  the  cluster  are  dead.  If  no  more  messages  are  in 
the  mailboxes  to  be  processed  and  all  the  APs  are  no  longer 
running,  the  MPU  invokes  its  final  shut-down  processing.  The  AP 
cluster  initialisation  data  is  saved  in  a  local  file  where  it 
will  be  used  during  the  next  IISS  or  cluster  start-up.  The 
MPU's  input  mailboxes  are  deleted  and  an  “A PC  Terminating11 
message  is  sent  to  the  Monitor  AP.  The  Message  Processing  Unit 
then  ends  execution. 
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SECTION  8 

LOGICAL  PARTITIONING  OF  SOFTWARE 


3.1  Monitor  Application  Process 

The  Monitor  AP  oonsists  of  five  major  modules  which  are 
executed  at  specific  times  during  the  IISS  execution.  MONITR. 
the  main  program  of  the  Monitor  AP,  calls  the  modules  associated 
with  the  five  major  functions.  Each  in  turn  call6  a  hierarchy  of 
nodules  which  provide  the  specific  functionality  of  the  Monitor 
AP.  The  topmost  levels  of  this  hierarchy  are: 

MONITR 

_ I _ 

II  I  II 

INTMTR  STRTUP  IMITAE  MTRSYS  SDMNTR 

The  functional  description  of  the  Monitor  AP  is  available  in  the 
NTM  Development  Specification  Il](l).  Structure  oharts  and 
nodule  descriptions  are  available  in  the  NTM  Product 
Specification,  Vol .  1  [2]. 

The  Monitor  AP's  functions  during  IISS  execution  are 
divided  between  the  IISS  Start-up,  System  Operation,  and  IISS 
shut-down  phases.  INTMTR,  and  STRTUP  control  IISS  Start-up. 
INITAE  initializes  asynchronous  processing  for  MTRSYS .  MTRSYS 
serves  as  the  focal  point  during  System  Operation  and  IISS 
shut-down.  MTRSYS  will  call  SDMNTR  to  handle  the  final 
shut-down  processing  of  the  Monitor  APC. 


(1)  References  are  made  to  documents  described  in  Section  5.2. 
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IISS  start-up  processing  begins  when  the  IISS  Operator 
invokes  the  Start-up  Command  file.  MONITR  begins  processing  by 
reading  a  sysgen  file  (2)  for  data  required  to  initialise  the 
Monitor's  AP's  common  data  (MTRCMN),  establishing  the  connection 
to  the  operator's  console,  and  creating  the  space  for  the  Global 
Host  Memory.  MONITR  then  calls  INTMTR  which  will  coordinate  the 
start-up  of  the  Monitor's  APC .  INTMTR  aooomplishes  this  by 
calling  the  next  level  routines  described  below.  An  overview  of 
the  start-up  procedure  is  given  in  Figure  5-1. 


•  CRTMBX :  Creates  the  Monitor  AP's  input  mailbox. 


•  BLDTBL:  Initializes  and  populates  the  host's  NTM 

global  tables. 


•  CRTPRC:  Spawns  the  Monitor  APC's  MPU. 


•  PRCTSR :  Waits  for  the  table  status  request  message 

from  the  Monitor  APC's  MPU.  If  any  other 
message  arrives  at  this  time,  it  will  be 
processed  in  accordance  with  its  type. 
Control  will  always  return  to  PRCTSR  until 
either  the  expected  message  arrives  or  the 
timeout  period  expires.  Upon  receipt  of  the 
expected  message,  the  table  status  return  is 
sent  to  the  Monitor  APC's  MPU. 


•  PRCSSR:  Waits  for  the  APC  Alive  status  message.  As 

in  PRCTSR  other  messages  will  be  processed 
if  they  arrive. 

•  APCSTS :  Called  if  the  APC  Alive  message  arrives 

before  the  timeout  period  expires.  Updates 
the  APC  status  table  and  displays  the  APC 
start-up  status  to  the  operator.  If  any 
links  to  other  hosts  are  active,  an  APC 
status  update  message  is  sent  to  the  Monitor 
AP's  of  these  hosts.  A  Host  Active  message 
is  also  sent  to  the  MPU. 


2)  The  sysgen  file  read  by  Monitor  and  the  MPU  is  described  in 
Section  4.1  of  this  document. 
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In  the  case  of  Monitor's  A PC  start-up,  an  AP  Alive  message 
is  sent  to  the  MPU  in  accordance  with  the  MPU-AP  Protoool .  This 
allows  the  MPU  to  enter  the  Monitor  AP  in  the  AP  Status  Table  to 
facilitate  further  message  processing. 

Upon  successful  completion  of  INTMTR,  the  Monitor  APs  APC 
is  fully  active.  The  next  steps  are  to  start  the  remaining 
APC' s  and  establish  the  network  communications  link.  These 
6teps  are  coordinated  by  STRTUP .  If  the  Monitor  AP  is  on  the 
VAX  (central  node),  the  CDM  APC  is  started  via  a  call  to  INITAC. 
If  the  Monitor  AP  is  on  a  non-VAX  (remote  node),  the  link  to  the 
central  node  is  established  via  a  call  to  LKTOCN.  In  either 
case,  the  following  routines  are  called. 

•  STLOAC:  Coordinates  the  start-up  of  the  local 

(on-host)  APC's  one  at  a  time.  Calls  INITAC 
for  each  APC  to  be  started. 

•  INITAC:  Sends  a  Start  APC  message  to  the  Monitor 

AP’s  and  calls  PRCTSR  and  PRCSSR  to  handle 
the  message  protocol.  APCSTS  is  called  on 
successful  start-up.  If  APC  start-up  fails. 
APCSTF  is  called. 

•  STNTCM :  Coordinates  the  star --up  of  the  links  to 

remote  hosts.  Starts  the  Communications 
Handler  AP  and  the  Link  to  remote  host.  If 
either  message  encounters  an  error,  STLNKF 
is  called  to  display  a  message  for  the 
Operator.  The  Link  status  message  will 
arrive  and  be  handled  during  the  system 
operations  phase. 

•  STCPLT:  Coordinates  the  remaining  start-up 

processing  by  sending  status  messages  to 
remote  hosts  (if  any  links  have  been 
established)  and  to  the  Local  APC's. 

3.1.2  System  Operations  Processing 

Upon  the  successful  completion  of  start-up,  MONITR  calls 
INITAE  to  set  up  the  Systems  Operations  Phase.  INITAE  issues 
reads  on  both  the  Operator's  console  and  the  Monitor  AP's  input 
mailbox.  The  XISS  start-up  banner  is  displayed  on  the  console. 

MONITR  then  calls  MTRSYS.  This  routine  waits  for  an  event 
to  occur,  either  at  the  console  or  the  mailbox.  Each  event  is 
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handled  as  it  occurs  with  control  returning  to  MTRSYS  when  the 
processing  is  complete.  The  two  aajor  paths  of  event  processing 
are  discussed  below. 


3. 1.2.1  Message  Event  Processing 

All  aessages  arriving  before  shut-down  processing  begins 
trigger  a  call  to  PRCMSG  which  acts  as  a  filter  by  reading  the 
aessage  type  froa  the  header  and  calling  the  appropriate  aessage 
handling  routine.  Each  aessage  type  reoeived  by  the  Monitor  AP 
has  its  own  routine.  A  aessage  having  a  type  not  reoognized  by 
PRCMSG  is  displayed  on  the  operator's  console. 

3. 1.2. 2  Console  Event  Processing 

All  console  events  trigger  a  call  to  PRCGON.  As  long  as 
shut-down  processing  has  not  begun,  PRCCON  will  call  XOPCMD  to 
interpret  the  coaaand.  XOPCMD  is  siailar  to  PRCMSG  in  that  it 
will  read  the  coaaand  and  call  the  appropriate  routine.  Each 
coaaand  has  its  own  controlling  routine. 


3.1.3  1ISS  Shut-down  Processing 

IISS  Shut-down  is  invoked  by  an  operator  coaaand  which 
triggers  a  console  event  to  MTRSYS.  The  coaaand  interpreter, 
XOPCMD,  calls  XSDCMD  to  coordinate  further  operator  input 
regarding  the  aaount  of  tine  before  the  actual  shut-down  begins. 
XSDCMD  obtains  the  tine  until  shut-down  and  calls  SHTDWN. 

SHTDWN  is  the  Bain  procedure  for  the  shut-down  processing.  This 
processing  is  partitioned  into  seven  phases  as  described  below. 


Phase  1 : 


Phase  2: 


Phase  3: 


If  tiae  until  shut-down  is  one  ainute  or 
aore,  this  phase  is  executed  to  infora  all 
users  on  the  systea  that  shut-down  is 
pending  (TELUSR) .  The  shut-down  coaaand  Bay 
be  cancelled  only  during  thi6  phase. 

This  phase  aarks  the  beginning  of  actual 
shut-down  processing.  During  this  phase, 
the  looal  non-coaponent  APC's  and  reaote 
hosts  are  told  to  shutdown  (SDRHMC).  At  the 
end  of  this  phase,  control  is  briefly  passed 
to  MTRSYS  to  wait  for  status  aessages. 

When  the  status  aessages  arrive,  MTRSYS 
oalls  SHTDWN  directly.  The  aessages  are 
processed  via  a  oall  to  SDSTAT .  SDSTAT 
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reads  the  message  type  and  calls  the 
appropriate  message  handling  routine. 


Phase 

4 : 

At  this  point,  the  network  communications 
links  are  shut-down  via  a  call  to  TRNTCM. 

Phase 

5: 

MTRSYS  waits  for  the  Link  Status  messages. 
These  messages  are  processed  by  SDSTAT. 

Phase 

6: 

All  remaining  Local  APC's  are  told  to 
shutdown  ( SDALCP ) . 

Phase 

7: 

Processes  the  status  returns  from  Phase  6  in 
the  manner  described  above  for  Phases  3  and 

5. 


At  the  end  of  Phase  7  control  returns  to  MONITR  which 
calls  SDMNTR  to  coordinate  the  shut-down  of  Monitor  AP's  APC. 
This  involves  an  exchange  of  shut-down  messages  between  the  AP 
and  the  MPU.  When  the  MPU  terminates,  the  shut-down  complete 
message  is  displayed  at  the  console.  The  input  mailbox  is 
deleted  and  the  connection  to  the  operator' s  console  is 
cancel  led. 

3.1.4  Monitor  Diagnostics 

Vhen  Investigating  problems  with  the  Monitor  AP,  the 
system  programmer  should  start  i/lth  one  of  the  high  level 
modules  and  work  downward  in  the  hierarchy.  The  state  that  the 
system  is  in  when  the  problem  occurs  can  indicate  where  to  begin 
looking  in  the  code.  For  instance,  if  the  error  occurs  prior  to 
notification  that  the  Monitor  APC  has  successfully  started, 
INTMTR  is  module  to  investigate.  From  the  point  at  which 
Monitor  APC  starts  until  start-up  is  complete.  Monitor  AP  is 
under  the  control  of  the  STRTUP  module.  If  start-up  is 
successful  but  Monitor  fails  before  the  NTM  banner  is  displayed 
to  the  operator  console  INITAE  is  the  place  to  look.  From  the 
time  at  which  the  operator  is  prompted  for  input  until  IISS 
shut-down  progresses  to  the  point  at  which  all  NTM  components 
have  terminated  except  the  Monitor  APC,  MTRSYS  is  the  module 
which  is  executing. 

Any  errors  during  INTMTR  processing  will  cause  the  Monitor 
AP  to  terminate.  The  error  code  and  message  displayed  to  the 
operator  console  will  indicate  the  nature  of  the  error  (see  the 
IISS  Network  Transaction  Manager  Operator's  Manual  [3]  for  a 
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description  of  the  NTM  error  codes). 

Certain  system  errors  during  STRTUP  will  cause  the  Monitor 
AP  to  fail.  If  a  component  APC  on  a  remote  node  fails  or  a 
remote-node's  communication  link  to  the  central  node  is  not 
established,  the  Monitor  AP  on  the  remote  node  will  terminate. 

3.1.5  Configuring  Monitor  AP 

When  Monitor  AP  is  to  be  configured  to  run  in  a  new  (or 
changed)  IISS  environment,  it  is  neoessary  to  update  the  system 
configuration  variables.  These  variables  are  added  to  (or 
modified  in)  the  sysgen  data  file  read  by  Monitor  at  startup. 

The  manipulation  of  this  file  is  discussed  in  Section  3.1. 

Monitor  AP  has  a  special  internal  table  which  is  used  to 
maintain  information  about  the  IISS  system  configuration.  A 
discussion  of  this  table  is  found  in  Section  3.2.1  of  this 
document . 

3.2  Message  Processing  Unit 

3.2.1  Logical  Structure  of  the  MPU  Code 

The  functions  of  the  Message  Processing  Unit  (MPU) 
component  of  the  NTM  can  be  divided  logically  between  the  APC 
Start-up,  APC  Operation,  and  APC  Shut-down  phases.  The  APC 
Operation  phase  includes  those  functions  required  to  handle 
messages  received  by  the  MPU.  These  messages  may  have  as  their 
source  either  an  on-cluster  Application  Process  or  another  MPU. 
The  values  given  in  the  message  header  dictate  the  path  to  be 
taken  through  the  code.  EXCMPU,  the  main  program  of  the  Message 
Processing  Unit,  controls  the  flow  of  these  MPU  phases.  Each 
phase  is.  in  turn,  controlled  by  its  own  main  program.  The  top 
of  the  hierarchy  is  given  in  Figure  3-2. 
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MPUXN1 

(MPU  Initialization  Routine) 
l 

EXCMPU 

(Main  MPU  Routine) 

I 


i 


i 


STRAPC 
(Main  APC 
Start-up  Routine) 


PRINPT 
(Main  APC 

Operations  Routine) 


TRMAPC 
(Main  APC 
Shut-down  Routine) 


Figure  3-2.  MPU  Logical  Structure 


Each  of  these  routines  will  call  lower  level  routines.  While 
the  calling  sequences  of  the  start-up  and  shut-down  phases  are 
pre-determined .  the  calls  made  during  APC  Operations  are  mostly 
determined  by  the  nature  of  the  message  being  processed. 

3.2.2  MPU  Start-up  Processing 

An  MPU  is  spawned  by  the  Monitor  AP's  MPU  ( NTMRVMPU )  upon 
request  from  the  Monitor  AP.  (The  Monitor  AP's  MPU  is  spawned 
directly  by  the  Monitor  AP.  This  is  the  only  deviation  in  the 
start-up  phase  of  any  MPU.)  Once  spawned,  MPUINI  begins 
operation  by  calling  "GETNAM*  (Section  5. 2. 1.3)  to  determine  its 
identity.  Using  the  AP  Name  returned  to  it,  MPUINI  reads  its 
sysgen  initialization  file  (See  Section  4.2  for  details). 
Information  from  this  file  is  read  into  INIDAT.Inc.  INIDAT 
contains : 

•  IISS  Instance 

•  The  last  serial  number  assigned  to  a  message  (saved 
from  the  previous  IISS  session) 

•  The  name  of  the  host  on  which  the  MPU  resides 

•  The  name  and  APC  location  of  the  host's  Monitor  AP 

•  The  name  and  APC  location  of  the  central  node's 
Monitor  AP 

•  Queue  Data  (maximum  allowed  in  quene,  maximum  last 
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key) 

•  The  name  of  the  COM's  AP  Cluster 

e  Timer  values 

e  The  naae  of  the  Coaaun  1  oat i on  Handler's  AP  duster 

#  The  naae  of  the  specific  MPU's  AP  cluster 

e  The  Process  Naae  of  the  specific  MPU 


The  structure  of  this  file  is  given  in  Section  3-2. 

Start-up  continues  by  napping  to  the  host  tables  via  a 
call  to  "MAPHST"  (Sec.  5.2.2. 3).  This  establishes  the  MPU's 
connection  to  the  systea  global  tables.  Upon  successful 
Initialization.  EXCMPU  is  called  to  handle  the  aain  MPU 
processing.  STRAPC  is  called  by  EXCMPU  to  coaplete  the  start-up 
processing.  STRAPC  in  turn  calls  four  next-level  routines  to 
handle  renaining  start-up  processing  and  nessage  protoool . 

e  INITST :  Opens  the  AP  duster's  files  and  logs  and 

creates  the  APC's  hot  and  cold  nailboxes. 
Upon  successful  coapletion.  STRAPC  sends  a 
Table  Status  Request  (TS)  nessage  to  the 
Monitor  AP. 

•  TABPRC :  Populates  the  A PC  static  Tables*  in 

accordance  with  the  Table  Status  Return  (ST) 
Message  froa  the  Monitor  AP.  If  the  status 
return  Indicates  that  the  tables  have 
changed ,  the  tables  are  populated  froa  the 
CDM .  If  there  is  no  change,  the  tables  are 
populated  via  a  series  of  initialization 
routines  (described  in  Section  3.4).  Local 
dynanic  table  headers  (for  those  tables 
having  no  population  requirement)  are  also 


'These  tables  are:  The  Authority  Table;  the  Authority  Check 

Table;  the  AP  Characteristics  Table,  and  the 
AP  Inforaation  Table. 
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initialised.  Upon  successful  completion, 
STRAPC  sends  an  APC  Alive  (LV)  message  to 
the  Monitor  AP. 

•  FSTART:  Waits  for  and  processes  final  6 tart-up 

messages  from  the  Monitor  AP.  The  final 
start-up  message  is  the  Host  Active  Message. 
In  the  case  of  the  Monitor  AP's  MPD.a 
rebuild  table  message  may  also  arrive  at 
this  time.  Upon  successful  completion, 
control  is  returned  to  EXCMPU  and  the  APC 
Operation  phase  begins. 

•  GDMSGS:  Processes  the  GDLOG  file  to  determine  if 

there  are  any  Guaranteed  Delivery  (GD) 
messages  that  need  to  be  processed.  The 
recovery  action  taken  by  GDMSGS  is 
determined  by  the  state  status  of  the  GD 
message  in  the  GDLOG. 


3.2.3  APC  Operations  Processing 

The  APC  Operations  Phase  is  controlled  by  PRINPT.  As  long 
as  the  APC  is  active,  control  is  passed  to  this  routine  upon 
completion  of  prior  processing. 

PRINPT  waits  on  one  of  three  events:  a  message  in  the  hot 
mailbox,  a  message  in  the  cold  mailbox,  or  a  timer.  Processing 
is  based  on  the  event  that  occurs  first.  The  routines 
associated  with  these  events  are  described  below. 

3.2.3. 1  Message  Event  Processing 

3. 2. 3. 1.1  Manage  Message 

The  arrival  of  a  message  in  either  the  hot  or  cold  mailbox 
starts  the  APC's  message  processing.  As  long  as  the  APC  is  not 
in  shut-down  mode  (or  the  message  is  an  AP  status  message  or  a 
system  command),  MNGMSG  is  called.  This  routine  examines  the 
message  header  to  determine  the  next  level  of  processing 
required  and  makes  the  following  calls  based  on  the  specified 
conditions . 

e  GDMSGS:  Called  if  the  message  from  off -cluster 

requires  Guaranteed  Delivery  processing 
(oategory  'A'  messages  from  off-cluster). 
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•  PRCONC:  Called  if  the  message  has  as  its  source  an 

on-cluster  AP.  PRCONC,  in  turn,  may  call 
the  following  under  the  specified 
conditions : 

e  VMSGCT:  verifies  the  message  category 
field  if  the  message  header  is 
new. 

e  POSAUT:  checks  the  level  of  authority 
required  by  the  destination  AP. 
If  the  destination  AP  is 
restricted,  a  call  is  made  to 
AUTMSG  to  verify  that  the 
message  is  authorized  for  its 
destination. 

e  CMPHDR:  if  there  are  no  errors  on  the 
messages,  validates  certain 
header  fields  and  calls  MPOINF 
to  supply  remaining  values. 

•  GDMSGS :  if  the  message  from  on-cluster 
(category  "A")  requires 
guaranteed  delivery,  creates  an 
entry  in  the  guaranteed  delivery 
table . 

e  ADDPR:  if  the  message  requires  pairing 

support ,  creates  an  entry  in  the 
Message  Pair  table. 

e  CHDPRC :  if  the  message  can  result  in  the 
initiation  of  an  AP,  creates  an 
entry  in  the  Child  Table. 


e  SNDSAP : 


if  the  source  AP  is  waiting  for 
an  acknowledgment  and  no  errors 
have  been  encountered,  formats 
and  sends  the  Message  ACK.  If 
an  error  oocurs  at  any  point  in 
this  message  processing,  SNDSAP 
will  be  used  to  send  the  error 
message  to  the  source  AP. 


•  VYOFFC : 


Called  if  the  message  has  as  its  source  an 
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off-cluster  AP  and  the  calling  MPU  is  not  on 
the  COMM  APC.  Verifies  that  the  message  has 
arrived  at  the  correct  MPU. 

•  RMVAST:  Called  if  the  message  is  from  off-cluster 

and  the  calling  MPU  is  on  the  COMM  APC. 
Removes  asterisks  placed  in  the  header  to 
facilitate  COMM  processing. 


Upon  completion  of  MNGMSG  functions,  control  is  returned  to 
PRINPT . 

3. 2. 3. 1.2  Process  Message 

ffhen  control  is  returned  to  PRINPT  and  if  there  are  no 
errors  on  the  message,  a  call  is  made  to  RTESND.  This  routine 
examines  the  message  header  to  determine  the  next  level  of 
processing  required.  The  following  calls  may  be  made  under  the 
specified  conditions. 

e  MNGPRC:  Called  if  the  message  destination  is  an 

on-cluster  AP.  MNGPRC  may,  in  turn,  call  the 
following  under  the  specified  conditions. 

e  APSTAT:  handles  AP  status  messages. 

Based  on  the  status  type,  will 
cal  1 : 

•  IMALIV:  upon  receipt  of  AP 

Alive  Message, 
handles  final  AP 
initiation 
processing . 

•  PRGDAK:  upon  receipt  of  a 

guaranteed  delivery 
message. 

•  APDEAD:  upon  receipt  of  AP 

Dying  Message, 
handles  AP 
termination 
processing  not 
covered  by  the  system 
service  TRMNAT. 
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•  SYSCOM : 


•  CHDSTM :  upon  reoelpt  of  a 

Child  AP  Status 
message,  handles 
child  table  updates. 

•  DELCLD:  upon  reoeipt  of  an 

unsuooessful 
initiation  return, 
deletes  the  relevant 
entry  from  the  child 
table. 


e  CHDPRC :  upon  receipt  of  an 
unsolicited 
initiation 
acknowledgment , 
updates  an  entry  in 
the  Child  Table. 


e  PFINIT:  Called  if  the  message  is  a 

specific  initiation  message  or 
where  it  appears  that  the 
message  requires  the  initiation 
of  an  AP.  This  routine 
verifies  that:  the  initiation 
is  required:  the  resources  are 
available:  and  that  the  AP  is 
not  in  an  abort  state.  If  no 
errors  are  encountered,  the 
initiation  is  performed  via  a 
call  to  either  INITAP  (where 
there  are  no  instances  of  the 
AP  currently  running)  or  PRINIT 
(where  there  are  instances 
running  -  PRINIT  may  in  turn 
oall  INITAP  if  the  AP  is  not 
running  the  maximum  instances 
al lowed) . 

Handles  NTH  system  commands  (generally 
messages  from  Monitor).  Based  on  the 
received  command,  this  routine  may  oall: 

e  SHUTAP :  to  shut-down  on  AP  (operator's 
command) 

e  SHTAPC :  to  shut-down  an  A PC  (operator's 
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•  INITAP : 

•  CLNHST: 

•  LISTPR: 

•  GDMSGS : 

•  CLNUP: 

•  ABORT: 

e  SDPEND : 

•  CNCLSD : 

•  HSTNRQ : 

•  DLVMSG : 

•  OFFCLQ : 


command  or  part  of  system 
shut-down) 

to  start  an  MPU  -  this  oall  is 
made  at  this  point  by  the  Monitor 
AP's  MPU  only. 

handles  processing  required  when  a 
remote  host  shuts  down. 

processes  the  request  for  a  list 
of  active  AP's  on-cluster 
(operator  command). 

handles  processing  of  Guaranteed 
Delivery  NTH  protocol  messages 
(MPU-GDACX ,  MPU-GDACKBACK ,  and  the 
ACK  from  a  user  AP) . 

processes  cleanup  command  (message 
from  Parent  AP's  MPU) 

processes  Abort  AP  commands 
(operator  command  or  request  from 
an  AP) 

process  shut-down  pending  message 

process  cancel  shut-down  message 

processes  requests  from  the  WHTHST 
service.  (What  host  is  this  given 
AP  on?). 

Called  where  the  message  is  to  be 
delivered  to  the  AP.  This  routine 
calls  SENDAP  to  check  the  AP's 
queues  for  outstanding  messages 
and  proceeds  to  write  the 
message(s)  into  the  correct 
mailbox  tint  11  all  messages  are 
delivered  or  the  AP's  mailbox  is 
full . 

Called  if  the  message  destination 
is  off-cluster.  If  the 
destination  is  on-host,  this 
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routine  checks  the  status  of  the 
destination  APC  and,  if 
aval lahle .writes  the  message  to 
that  MPU's  mailbox.  If  the  mailbox 
is  full,  the  message  is  queued  for 
later  delivery.  If  the 
destination  is  off-host,  RTESND 
adds  asterisks  to  the  header  and 
OFFCLQ  writes  the  message  to 
OOMM's  MPD . 


Upon  completion  of  RTSEND  functions,  control  is  returned  to 
PRIMPT. 


3.2. 3. 2  Timer  Event  Processing 

As  previously  mentioned,  PRIMPT  waits  on  a  timer  event  as 
well  as  the  mailbox  events.  Upon  the  occurrence  of  a  timer 
event,  PRINPT  will  call  the  TIMCHK  routine  to  perform  actions 
required  by  the  timer.  TIMCHK  oalls  the  following  routines  to 
perform  the  time-related  ohecks  on  tables  and  queues. 


•  PAIRCK : 


•  IATCHK: 


e  SEMDAP : 


e  OFFCLQ: 


#  CLDCHK: 


Reads  the  message  pair  table  for  messages 
that  have  not  received  a  required  response 
in  the  allotted  time.  Timed  out  messages  are 
deleted  from  the  table  and  error  messages 
are  sent . 

Reads  the  I'm  Alive  table  for  APs  that  have 
not  sent  I'm  Alive  messages  within  the 
allotted  time.  Where  the  AP  has  not 
responded,  its  table  entry  is  deleted  and  an 
unsuccessful  initiation  message  is  sent. 

Checks  for  messages  queued  for  delivery  to 
on-cluster  APs.  If  the  AP  is  now  available, 
the  message  is  delivered. 

Checks  for  messages  queued  for  delivery  to 
off -cluster  APs.  If  the  destination  APC  is 
now  available,  the  messages  will  be 
delivered. 

Reads  the  child  table  for  reserved  entries 
that  have  not  been  confirmed  via  unsolicited 
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init  ACK's.  Any  entry  reserved  for  more 
than  the  allotted  time  will  be  deleted. 


3. 2. 3. 3  Guaranteed  Delivery  Processing 

When  an  application  submits  a  Guaranteed  Delivery  (GD) 
message  to  the  NTM  by  calling  GDSEND,  a  GD  message  (category  A) 
is  formatted.  When  the  source  MPD  receives  this  message,  it 
processes  the  message  and  logs  it  in  the  GD  log  (PRCONC  calls 
GDMSGS)  before  returning  an  acknowledgement  that  contains  the 
message  serial  number  to  the  sending  AP.  The  MPUs  continues 
processing  this  GD  message  by  keeping  tract  of  the  state  of  the 
message  in  the  GD  log.  Before  an  MPU  considers  its 
responsibility  for  theGD  message  complete,  it  must  receive  an 
acknowledgement  from  the  destination  MPU  (message  type  ”GX")  and 
return  to  it  a  MPU  GO-ACKBACK  (message  type.  “GY" ) .  This 
protocol  supports  a  hand-off  mechanism  that  allows  recovery 
based  on  the  states  of  the  messages  in  the  GD  log  to  take  place. 

When  an  MPU  (non-comm)  receives  a  GD  message,  it  calls 
GDMSGS  from  MNGMSG  to  log  the  incoming  GD  message  and  sends  a 
"GX”  type  ack  to  the  sending  MPU  before  handing  the  message  off 
to  MHGPRC  for  the  required  process  management  and  message 
delivery  to  the  destination  AP  (via  SENDAP) . 

The  NTM  internal  GD  protocol  messages  are  sent  as  system 
messages  (category  ”C"  messages)  and  processed  by  SYSCOM.  The 
GD  destination  AP  must  generate  a  GD  ACK  (by  calling  GDACK)  when 
it  has  completed  its  GD  processing.  This  GD  ACK  message  is 
given  a  category  of  C,  for  system  message,  and  processed  by 
SYSCOM . 

The  GD  protocol  is  described  in  Figure  3-3. 


3-16 


SUM620 142000 
1  November  1985 


1.  AP  calls  service  to  request  the  delivery  of  a  GD 
•ess age. 

2.  GD  message  sent  to  local  MPU. 

3.  The  local  MPU  processed  the  GD  request  and,  if 
aocepted,  logs  the  GD  message  in  the  GD  log  file 
and  makes  a  short  status  entry  in  the  GD  table 

4.  The  local  MPU  sends  an  acknowledgement  to  the  AP 
(received  by  GDSEND). 

5.  GDSEND  returns  control  to  the  requesting  AP  with 
status  and  GD  message  serial  number. 

6.  The  GD  message  is  delivered  to  the  destination  MPU 
(when  it  is  available) 

7.  The  receiving  MPU  logs  the  message 

8.  The  receiving  MPU  sends  an  MPU  GDACK  to  the  sending 
MPU  (type  "GX"). 

9.  The  source  MPU  sends  an  ACKBACK  (type  "GY")  to  the 
destination  MPU;  signalling  its  handoff  of  the  GD 
message  and  deletes  the  GD  log  record  from  its 
file. 

10.  The  destination  MPU  delivers  the  GD  message  to  the 
destination  AP  (when  it  is  available). 

11.  The  destination  AP  sends  a  GD  acknowledgement 
(calls  GDACK)  when  it  has  completed  its  GD 
processing. 

12.  On  receipt  of  the  GDACK  from  the  destination  AP. 

The  destination  MPU  removes  its  record  of  the  GD 
message  and  forwards  the  GD  ack  to  the  source  MPU. 

13.  The  source  MPU,  on  receipt  of  the  AP's  GD  Ack, 
removes  the  status  entry  for  the  GD  record  from  its 
GD  status  table. 


Figure  3-3.  Guaranteed  Delivery  Protocol 
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3.2.4  Shut-Down  Phase  of  the  MPU 


During  the  shut-down  phase  of  the  Message  Processing  Unit, 
processing  continues  in  a  mode  similar  to  the  APC's  Operations 
phase.  PRINPT  continues  to  read  messages  from  the  mailboxes 
(although  there  are  no  waits  for  mailbox  events  in  the  shut-down 
phase).  Routines  that  process  AP  Status  messages  and  system 
commands  may  still  be  called.  The  time-checking  routine  is  not 
used  during  shut-down.  In  addition  to  the  message  processing 
routines  described  above,  there  are  certain  routines  that  are 
called  only  during  the  shut-down  phase.  These  are: 


•  SDMODE :  Called  by  PRINPT  to  process  messages  after 

the  shutdown  phase  has  begun.  This  routine 
screens  the  incoming  messages  for  AP  Status 
Messages  and  System  Commands.  All  other 
messages  may  be  logged  but  are  not 
processed. 

e  SHTAPC :  Called  by  SYSGOM  to  shut  down  all  AP's  on 

the  cluster. 


•  SFTSD:  Called  by  SHTAPC  to  shut  down  on-cluster 

AP's  having  the  internal  logic  to  shut 
themselves  down.  (AP's  not  having  internal 
shut-down  logic  are  aborted  in  SHTAPC.) 


Once  the  shut-down  of  all  the  APs  on  the  cluster  is  complete  and 
all  messages  have  been  processed,  the  Message  Processing  Unit 
calls  its  final  program,  TRMAPC .  TRMAPC  deletes  the  mailboxes, 
writes  the  initialisation  data  to  the  start-up  file  and  informs 
the  Monitor  AP  that  the  MPU  is  terminating. 

3.2.5  Error  Handling  by  the  Message  Processing  Unit 

Most  errors  occurring  within  the  MPU  will  be  sent  to  the 
Monitor  AP  via  the  Monitor  MPU  where  they  will  be  displayed  on 
the  operator's  console.  These  messages  show  which  MPU  the 
message  came  from  (the  cluster  on  which  error  was  detected)  and 
what  type  of  error  has  oocurred  (error  oodes  are  defined  in  the 
Operator's  Manual  [3]  and  the  IISS  Programmer's  Guide  [4]).  The 
routines  used  to  send  these  messages  to  the  Monitor  AP  are 
SMDMTR  and  8MDM0H.  In  most  cases,  SNDMOH  is  used  to  send  the 
message  via  the  Monitor's  MPU;  however,  during  start-up  on  the 
Monitor  duster,  SNDMTR  is  used  to  send  the  message  directly  to 
the  Monitor  AP's  mailbox. 
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Error  messages  of  interest  to  the  message  souroe  AP  are 
also  sent.  Zn  some  cases,  these  messages  will  be  interpreted  by 
the  AP  Interface.  In  the  case  of  a  "SIGERR"  message,  the  AP 
will  handle  it  itself. 

3.2.6  Debugging  the  Message  Processing  Onit 

Debugging  (especially  during  start-up  when  there  are  no 
message  logs)  can  be  made  easier  by  using  the  routine  MBXLOG.  A 
debug  buffer  of  seventy-two  characters  must  be  used  when  calling 
MBXLOG.  For  example,  if  a  programmer  debugging  an  MPU  COBOL 
routine  needed  to  know  the  values  of  two  data  items,  MBXLOG 
could  be  used  in  the  following  way: 

01  DEBUG-BUF. 

03  DEBUG-BUF- 1  PIC  X(36). 

03  DEBUG-BUF-2  PIC  X(36). 

MOVE  DATA- ITEM- 1  TO  DEBUG- BUF-1. 

MOVE  DATA- ITEM-2  TO  DEBUG-BUF-2. 

CALL  -MBXLOG*  USING  DEBUG-BUF. 

Both  data  items  will  be  written  to  the  MBXLOG  file  associated 
with  that  AP  cluster  (e.g. ,  MRVMBX.DAT,  UIVMBX.DAT,  00VMBX.DAT, 
...).  These  files  will  be  emptied  during  clean-up. 

Also  during  the  start-up  of  a  cluster,  messages  may  time 
out  if  an  error  oocurs.  When  debugging  it  may  be  useful  to 
raise  and  lower  the  timeout  time  as  needed.  The  timeout  value 
during  start-up  is  set  in  the  sysgen  file. 

During  regular  input  processing  the  time  checking  routine 
is  invoked  upon  the  timer,  and  again,  it  may  be  useful  to  raise 
or  lower  the  timer  to  the  debugging  needs.  This  time  value  is 
also  set  in  the  sysgen  file.  Manipulation  of  the  values  in  the 
sysgen  file  is  discussed  in  Section  3.1  of  this  document. 

3 . 3  NTM Services 


The  NTM  Services  are  a  set  of  COBOL  routines  that  are  used 
by  IISS  Application  Programs  (APs)  for  communicating  with  other 
IISS  APs  and  the  NTM.  The  NTM  Service  routines  are  called  by 
the  APs  with  COBOL  CALL  Statements  that  are  described  in  the 
IISS  Programmer' 6  Guide  [4].  These  Services  provide  the 
interface  between  an  AP  and  the  NTM  by  establishing,  servicing, 
and  disconnecting  NTM  mailbox  connections  for  the  AP  (Figure 


3-19 


SUM620 142000 
1  November  1985 


5-4).  These  mailbox  service  functions  provide  a  logical 
organization  of  the  NTH  Communication  Services  into  the 
Initiation,  Communication,  and  Termination  classes  listed  in 
Figure  3-5.  Another  category  of  the  NTM  Services  contains 
status  or  information  request  servioes.  Currently,  there  are 
three  Status  Services  available,  GETUSR,  CHGROL,  and  WHTHST. 

The  NTM  Services  use  the  Interprocess  Communication 
Primitives  (IPCs)  to  implement  the  AP's  mailbox  communication 
requests.  Hence,  an  AP's  code  must  be  bound  or  linked  with  both 
the  NTM  Services  and  the  IPCs.  If  an  AP  uses  any  CDMP  (Neutral 
Data  Manipulation  (NDML)  Language )  or  01  (Forms  Processor  (FP) 
or  Virtual  Terminal  Interface  (VTI))  Services,  these  CDMP  and  UI 
routines  must  also  be  bound  with  the  AP  to  give  the  AP's 
executable  unit  (Figure  3-6). 

The  following  sections  describe  the  processing  of  the 
individual  services  within  each  of  the  four  service  classes  - 
initiation,  communication,  termination,  and  status. 

Section  3.3.5  describes  the  error  handling  implementation 
in  the  Service  routines.  An  Interpretation  guide  of  the  error 
diagnostics  for  service  debugging  is  also  provided. 
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1.  In  implementation,  APs  that  can  process  NT*  commands  (i.e., 
shutdown)  will  have  two  input  mailboxes.  The  second  irput 
mailbox  will  be  used  to  receive  these  high  priority  insollcitec 
messages  from  the  NT*. 


Figure  5-4.  AP  Mailboxes 
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INITIALIZATION 

COMMUNICATION 

TERMINATION 

XNITAL 

NSEND 

TRMAT 

INITEX* 

I  SEND 

LOGOFF 

INICOM*  * 

RCV 

TRMNAX** 

LOGON 

CHKMSG 

TSTMOD 

SIGERR 

*  INITEX  is  used  by  the 

Ul  APs  only 

**  INICOM  and  TRMNAX  are 

used  by  the  COMM  APs 

only 

Figure  3-5.  NTM  Services 

AP  Code 

FP  B  VTI 

l 

l 

Database 

Services 

l 

Services 

NTM  Services 


I  PCs 


Figure  3-6.  IXSS  AP  Code  Unit 
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3.3.1  NTH  Initiation  Servloes 


The  NTM  Initiation  Services  are  coaprised  of  three 
slightly  different  initiation  routines  (XNXTAL,  XMXTEX,  mm* 
INIOOM)  that  support  variations  in  the  initiation  requireaents 
between  the  generic  XXSS  APs,  the  DX  AP,  and  the  COMM  AP.  These 
initiation  routines  and  a  description  of  their  use  are  in  Figure 
3-7. 


LOGON  is  also  a  service  in  the  initiation  category.  It  is 
used  by  the  UI  to  send  XXSS  logon  inforaation  to  the  NTM's 
Monitor.  The  Monitor  keeps  this  logon  data  stored  in  a  table  to 
support  user  status  requests  froa  APs  (GETUSR)  and  the  XXSS 
Operator . 

The  XISS  architecture  calls  for  an  AP  to  be  able  to  send  a 
aessage  (the  ‘I 'a  Alive"  aessage)  to  its  local  MPU  before  it 
receives  any  aessages  froa  the  MPU.  This  requires  the  MTM 
Services  to  know  the  local  MPU's  aailbox  naaes  at  initiation 
tiae.  These  MPU  aailbox  naaes  are  derived  froa  the  cluster's 
( APC)  naae.  For  exaaple.  the  UIV  duster's  MPO  aailbox  naaes 
are  XUIVC  and  XUIVH,  which  signify,  respectively,  the  MPU's  cold 
and  hot  aailbox  naaes.  where  "X"  is  the  IISS  instance  in  which 
the  MPU  is  running. 

The  requireaent  for  the  MPU's  aailbox  naaes  to  be  known  or 
"hard-coded"  has  been  iapleaented  by  having  an  include  file, 
APCNAM,  that  contains  the  APC  naae  neoessary  to  fora  the  local 
aailbox  naae.  Hence,  each  APC  requires  a  separately  coapiled 
copy  of  the  initiation  routine  that  has  the  correct  APC  naae  in 
the  APCNAM. INC  file.  For  exaaple.  APCNAM  for  the  UIV  cluster 
consists  of  the  following  declarations: 


THE  HARD-CODED 
HAVE  A  VALUE. 

A  PC -NAME _ FOR 

EACH  APC . MUST 

01 

APCNAME 

PIC  X(3) 

VALUE  "UIV". 

01 

UI 

PIC  X( 3) 

VALUE  "UIV". 

01 

COMM 

PIC  X( 3) 

VALUE  "00V". 

01 

MON-PRIME 

PIC  X(10) 

VALUE  "MTMONITV" 

01 

MOM-PRIME-APC 

PIC  X( 3) 

VALUE  "MRV" . 
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Initiation 


Service 

User 

Call  Statement 

Functions 

INITAL 

ALL  I1SS 

CALL 

“INITAL"  USING 

1. 

Initiates 

AP's  other 

BUFFER, 

NTM  Data 

than  COMM 

BUFFER-SIZE, 

Structures 

and  UI 

SYSTEM-STATE 

2. 

Creates  AP's 

RET -CODE 

3. 

mai  1  boxes 

Sends  ‘I'm  Alive" 
message  to  NTM 

4. 

Receives  System 
State  Information 

5. 

Returns  System 
State  Information 

INITEX 

DI 

CALL 

“INITEX"  USING 

1. 

Functions  1-4 

BUFFER, 

of  INITAL. 

BUFFER-SIZE. 

(No  System  State 

RET-CODE. 

information  is 

returned  to  the 
AP.)  Performs  an 
"external " 
connection  to  the 
NTM  (the  NTH  does 
not  create  the  01 
process . ) 


INICOM  COMM 


CALL  ■ INICOM"  USING 


1.  Functions  2-3 
COMM ~RCV -EVENT- BLOCK ,  of  INITAL. 

2 .  Returns  the 
mailbox  names  to 

COMM  for  its  use 
in  NTM 

comnun i cat i on . 


INPOT-MBX-NAME , 
APC-HOT-MBX-NAKE , 
APC-COLD-MBX-NAME , 
RET -STATUS . 


Figure  3-7.  INITAL,  INITEX,  and  INICOM 
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In  order  to  maintain  the  bookkeeping  of  which  APCNAM  is  to 
be  linked  with  the  initialization  service  for  a  given  AP,  each 
version  has  a  unique  extension  associated  with  the  file  name. 

At  present  there  are  two  versions;  APCNAM. LI 1  for  the  User 
Interface  APC(UIV).  and  APCNAM. LI2  for  the  Testing  APC(TIV). 

3. 3. 1.1  INITAL 

The  NTM  initiation  service  for  generic  APs  is  INITAL.  The 
service  has  four  major  functions:  creating  the  AP's  input 
mailbox(es),  initializing  the  global  data  structures  that  are 
managed  by  the  NTM  services  for  the  AP,  informing  the  local  NTM 
component  that  the  AP  has  completed  the  initiation  procedure 
(announcing  “I'm  Alive"),  and  receiving  system-state  information 
from  the  NTM  for  the  AP.  The  implementations  of  these  four 
functions  are  described  in  the  following  paragraphs. 

3. 3. 1.1.1  Creating  the  AP's  Input  Mailboxes 

INITAL  creates  the  AP's  input  mailboxes  by: 

1.  Determining  the  AP's  process  name  with  a  call  to 

GETNAM.  The  AP's  ten  character  process  name  (8 

character  AP  name  plus  2  character  instance 
identifier)  returned  by  GETNAM  is  the  one  used  by 
the  MPU  to  create  the  process. 

2.  Using  the  process  name  determined  in  Step  1  as  the 

base  of  the  AP's  mailbox  names  -aC,  H  or  A  is 

appended  to  this  base  to  form  the  cold,  hot  and  ACK 

mailbox  names. 

3.  Calling  the  IPC  primitive,  CRTMBX,  to  create  the 
AP's  hot,  cold  and  ACK  mailboxes.  The  creation  of 
mailboxes  is  dependent  on  the  number  of  mailboxes 
the  given  AP  supports.  Thi 6  information  is  obtained 
from  th  AP  characteristics  table  and  passed  to  the 
AP  Interface  in  the  System  State  Message.  In  order 
to  receive  the  system  state  message,  the  cold  and 
ACK  mailboxes  will  always  be  created.  Depending 
upon  the  actual  number  of  mailboxes  supported  by 
the  AP,  the  AP  interface  will  either  create  a  hot 
mailbox,  delete  the  cold  and  ACK  mailboxes,  or 
leave  things  as  they  stand. 
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3. 8. 1.1. 2  Initializing  AP  Global  Data  Structures 

The  Serviees  maintain  a  global  data  section  consisting  of 
three  include  files  to  provide  message  integrity  for  the  AP. 

The  VAX  global  section  is  listed  in  Figure  3-8.  Three  olasses 
of  data  are  maintained  in  this  section: 

•  APC  and  AP  names  used  in  message  headers  and 
mailbox  names 

•  Buffers  for  saving  AP  messages,  accepted  headers, 
and  message  pairing  information 

•  Flags  that  indicate  state  information 

During  initialization,  the  buffers.  HEADER-BUFFER, 
RESPONSE-TABLE,  and  ROUTING-TABLE  are  cleared.  Their  respective 
pointers.  NO-IN-HDR-BUFFER,  NO-IN-RESPONSE-TABLE,  and 
NO-IN-ROUTING-TABLE  are  set  to  zero. 

Limits  for  the  global  buffers  and  other  data  that  are 
considered  as  "local*  service  data  are  kept  in  APILCL.INC. 
(Figure  3-9) 

3. 3. 1.1. 3  Informing  the  NTM  That  the  AP  Is  Alive 

After  the  AP's  cold  and  ACK  mailboxes  have  been 
successfully  created,  an  'I'm  Alive”  message  is  formatted 
(ALMSGH. INC)  and  sent  to  the  local  MPU.  If  the  MPU's  mailbox  is 
full,  the  send  is  retried  a  set  number  of  times  before  returning 
an  unsuccessful  status  to  the  user. 

3. 3. 1.1. 4  Receiving  System-State  Information  from  the  NTM 

If  the  "I'm  Alive"  message  was  successfully  sent  to  the 
MPU,  INITAL  issues  a  "RCVMSG" .  a  "SETTIM"  to  set  a  wait  time  for 
the  System  State  message,  and  then  a  "WAIT02”.  If  the  event 
returned  on  the  "WAIT02"  is  a  timer  event,  an  unsuccessful 
IMITAL  return  is  given  to  the  AP.  On  a 
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API-GLOBAL-BUFFER-SEC  EXTERRAL. 

03  NO-IN-HDR-BUFFER  PIC  9(9)  COMP. 

03  HEADER-BUFFER 

05  KDR-SAVE  PIC  X(92) 

OCCURS  9  TIMES. 


PIC  X(10). 
PIC  X(3) . 
PIC  X(7) . 
PIC  X. 

PIC  9(4) 


03  MSG-PAIR-TABLE. 

05  PAIRS  OCCURS  10  TIMES 
10  PR-DESTIHATION 
10  PR-CHAMNEL-ID 
10  PR-SERIAL-NO 
10  PR-ACX-FLG 
03  NO- IN-PAIR-TABLE 
03  MSG-RCV-BUFFER . 

05  REC-MSG  OCCURS  20  TIMES 

03  BUFFER-OVERFLOW -AREA 
03  BUFFER-OVERFLOW-FLAG 
88  EMPTY -OVERFLOW 
88  FULL-OVERFLOW 
03  NO-IN-RCV -BUFFER 
03  RESPONSE-TABLE. 

05  RESPONSES -WAITING 
10  RESPONSE-CHANNEL 
10  RESPONSE-DEST-PRONME. 

15  RESPONSE-DEST-APNAME 
15  RESPONSE-INSTANCE 
10  RESPONSE -SERIAL-NO 
03  MO- IN-RESPONSE-SERIAL-NO 
03  ROUTING-TABLE. 

05  ROUTING-ENTRY  OCCURS  8  TIMES. 


PIC  9(4) 


COMP. 

PIC  X(2000). 
PIC  X(2000). 
PIC  X. 

VALUE  “O’ 
VALUE  “1“. 
COMP. 


OCCURS 


10  TIMES. 

PIC  X(3) . 

PIC  X(10). 
PIC  X(2) . 

PIC  X(7). 

PIC  9(4)  COMP. 


10  ROUT-APNAME 
10  ROUT- INSTANCE 
10  ROUT-APNAME 
03  NO- IN-ROUTING-TABLE 


PIC  X(10). 

PIC  X(2) 

PIC  X(3) 

PIC  9(4)  COMP. 


Figure  3-8a.  BUFAPI . INC 
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01 


API -GLOBAL-NAME -SEC 

EXTERNAL. 

03  STSGEN- INSTANCE 

PIC  X. 

03  A PC -NAME 

PIC  X(3) 

03  APNAME 

PIC  X(10). 

03  MAP-PRONME 

PIC  X( 12) . 

03  OIAPCNAME 

PIC  X(3) . 

03  COMMAPCNAME 

PIC  X(5) . 

03  MON-ON-PRIME 

PIC  X(10). 

03  MON -ON -PR I ME -APC 

PIC  X(3) . 

03  SYSTEM-STATE-BLOCK. 

04  SYSTEM-STATE 

PIC  X. 

88  INITIAL-RECOVERY 

VALUE  "I1*. 

88  INITIAL-IISS-START 

VALUE  “2" . 

88  INITIAL-NORMAL 

VALUE  "3" . 

88  INITIAL-FIRST-RON 

VALUE  "4". 

04  LOG-CHAN 

PIC  X(3). 

04  ORIGINAL-SOURCE. 

05  OS-PRONME. 

10  OS -APNAME 

PIC  X(10). 

10  OSOINSTNC 

PIC  X(2) . 

10  OS-APCNME 

PIC  X(3) . 

04  MPU- INSTANCE 

PIC  XX. 

04  NUM-OF-MBXS 

PIC  X. 

Figure  3-8b.  APZNME.ZNC 


01 

HOT-MBX -EVENT -BLK 

PIC 

X( 2032) 

IS 

EXTERNAL . 

01 

OOLD-MBX-EVENT-BLK 

PIC 

X(2032) 

IS 

EXTERNAL . 

01 

SEND-EVENT-BLK 

PIC 

X( 2032) 

IS 

EXTERNAL . 

01 

ACK-MBX  EVENT- BLK 

PIC 

X( 2032) 

IS 

EXTERNAL . 

01 

TIMER -EVENT -BLK 

PIX 

X( 8 )  IS 

EXTERNAL 

Figure  3-8c.  APIEVB.ZNC 
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01 

DATA-MSG-LENGTH-MAX 

PIC  9(4) 

COMP  VALUE  1908. 

01 

gold-mbx-event-no 

PIC  99 

VALUE  5. 

01 

HOT-MBX-EVENT-NO 

PIC  99 

VALUE 

2. 

01 

TIMER -EVENT -NO 

PIC  99 

VALUE 

4. 

01 

ACK-MBX -EVENT -MO 

PIC  99 

VALUE 

5. 

01 

EVENT-NUMBER 

PIC  99. 

01 

MO-OF-EVENT-BLKS-1 

PIC  99 

VALUE 

1. 

01 

NO-OF -EVENT-BLXS-2 

PIC  99 

VALUE 

2. 

01 

SEND-WAIT 

PIC  99 

VALUE 

08. 

01 

RCV-WAIT 

PIC  99 

VALUE 

59. 

01 

MAX-NO-TRIES 

PIC  9(4) 

COMP  VALUE  6. 

01 

MAX- IN-HDR-BUFFER 

PIC  9(4) 

COMP  VALUE  9. 

01 

MAX- IN-RCV-BUFFER 

PIC  9(4) 

COMP  VALUE  20. 

01 

MAX-IN-PAIR-TABLE 

PIC  9(4) 

COMP  VALUE  10. 

01 

MAX- IN-RESPONSE-TABLE 

PIC  9(4) 

COMP  VALUE  10. 

01 

MAX - IN -ROUTING-TABLE 

PIC  9(4) 

COMP  VALUE  8. 

01 

ACK-MBX-NAME . 

05  A  I I SS- INSTANCE 

PIC  X. 

05  A -MBX - PRONME 

PIC  X( 12) . 

05  A-MBX-TYPE 

PIC  X 

VALUE 

"A"  . 

01 

OOLD-MBX-NAME. 

05  C-IISS-INSTANCE 

PIC  X. 

05  C-MBX-PRONKE 

PIC  X( 12) . 

05  C -MBX -TYPE 

PIC  X 

VALUE 

"C"  . 

01 

HOT-MBX-NAME . 

05  H-IISS-INSTANCE 

PIC  X. 

05  H-MBX-PRONME 

PIC  X( 12) . 

05  H-MBX-TYPE 

PIC  X 

VALUE 

"H"  . 

01 

APC-COLD-MBX-NAME . 

05  APC-C- I I SS- INSTANCE 

PIC  X. 

05  C-APC-NAME 

PIC  X( 3)  . 

05  C-APC-TYPE 

PIC  X 

VALUE 

"C"  . 

05  FILLER 

PIC  X(9) 

VALUE 

SPACES 

01 

MSG-BUFFER-SIZE 

PIC  9(4) 

VALUE 

2000. 

01 

NUMBER-OF -BYTES 

PIC  9(4) 

01 

WAIT-TIME. 

05  WAIT-HRS 

PIC  99 

VALUE 

ZERO. 

05  WAIT-MIN 

PIC  99 

VALUE 

ZERO. 

05  WAIT-SEC 

PIC  99 

VALUE 

• 

ZERO. 

Figure  5-9. 

NTM  Services  Local  Data 
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01  HOT-NBX-SIZE 
01  COLD-MBX-SIZE 
01  ACK-MBX-SIZE 
01  MSG-BUFFER 
01  MSG-SIZE 
01  TRIES 

01  NONE- IN-BUFFER-OVERFLOW 

01  ONE- IN-OVERFLOW 
01  MBX-FULL 
01  SYS-CAT-RESPONSE 
01  SYS-CAT-NORES 
01  CAT-RESPONSE 
01  CAT-UBSOLICITED 
01  SPECIFIC- INITIATION 
01  SPEC- INIT-PAIR 
01  FIND-A-ROUTING-ENTRY 
88  ROUTING-SPACE 
88  NO-ROUTING-SPACE 


PIC  9(5) 

VALUE  2100. 

PIC  9(5) 

VALUE  2100. 

PIC  9(5) 

VALUE  200. 

PIC  X( 1908 ) 

PIC  9(4) 

VALUE  2000. 

PIC  9(4) 

COMP . 

PIC  X 

VALUE  “0". 

PIC  X 

VALUE  " 1 - . 

PIC  X(5) 

VALUE  "1001". 

PIC  X 

VALUE  "D" . 

PIC  X 

VALUE  "C" . 

PIC  X 

VALUE  "F" . 

PIC  X 

VALUE  "E" . 

PIC  X 

VALUE  "H* . 

PIC  X 

VALUE  " J" . 

PIC  X( 3) . 

VALUE  "YES". 
VALUE  "NO". 

Figure  3-9.  NTH  Services  Local  Data 
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mailbox  event,  the  System  State  data  is  obtained  and  saved  in 
the  SYSTEM-STATE-BLOCK  in  the  global  data  section  (APZNME. INC) . 
If  needed,  mailbox  processing  is  completed  after  which  a 
successful  XNITAL  return  is  given  to  the  AP,  along  with  the 
System-State  Value. 

3. 3. 1.2  INXTEX 

INITEX  is  the  initiation  service  that  is  used  by  the  User 
Interface  (UI)  to  perform  an  external  connection  to  the  NTH.  An 
external  connection,  where  a  running  process  attaches  to  the 
NTH,  is  necessary  because  of  the  UX  terminal  attachment  design. 
The  only  logic  differences  between  INITAL  and  INITEX  are  the 
fol lowing: 

•  INITEX  does  not  return  the  System  State  value  to 

the  UI.  This  is  because  the  UI  does  not  need 
recovery  or  special  restart  data. 

e  Since  the  UI  must  process  high-priority  messages 

from  the  NTM,  the  UI  APs  require  two  input 
mailboxes.  Hence,  there  is  no  need  for  INITEX  to 
determine  the  number  of  input  mailboxes  for  the  UI . 
NUM-OF-MBXS  has  value  “2". 

3. 3. 1.3  INIOOM 

INICOM  is  the  initiation  service  that  is  used  by  the  COMM 
APs.  Because  COMM  directly  handles  the  mailbox  sends  and 
receives  between  it  and  the  NTM,  there  are  some  differences  in 
the  parameter  requirements  between  INITAL  and  INICOM.  The  call 
tc  INICOM  has  the  following  format. 

Call  "INICOM"  USING  COMM -RCV- EVENT -BLOCK , 

XNPUT-MBX-NAME , 

APC-HOT-MBX-NAME , 

APC-COLD-MBX-NAME , 

RET-STATUS . 

INICOM  s  functions  consist  of  : 
e  Creating  COMM's  input  mailbox. 

e  Sending  the  COMM's  "I'm  Alive”  message  to  the  local 

MPU. 

e  Returning  the  mailbox  names  and  initiation  status 
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(RET- STATUS)  to  the  COMM  AP . 

NOTE:  Because  of  the  IPC  requirement  for  the  event-block 
address  used  in  the  CRTMBX  call  to  be  the  one  used 
in  all  RCVMSG  on  that  mailbox,  the  COMM  AP  must 
pass  the  input  mailbox  event  block  address  to 
IN1COM . 

3 . 3 . 1 . 4  LOGON 


LOGON  is  the  service  used  by  the  UZ  to  transmit  IISS 
terminal  LOGON  information  to  the  NTM.  After  an  IISS  users 
logon  has  been  accepted  by  the  UI,  it  calls  LOGON  with  the 
statement : 

Call  "LOGON"  USING  TERMINAL-ID. 

USER-NAME . 

ROLE -NAME. 

SESSION-START-TIME . 

CHAN-RANGE-START . 

CHAN-RANGE-END. 

RET-OODE . 

The  LOGON  Service  formats  an  NTM  message  that  contains  the 
data  received  in  the  CALL  arguments  and  sends  the  message  to  the 
MONITOR  on  the  primary  Host  Via  the  local  MPU.  The  message 
structure  is  in  LGNMSG . INC .  Control  is  returned  to  the  calling 
AP  upon  receipt  of  a  message  from  the  Monitor  AP  containing  the 
status  of  the  Logon  entry.  If  the  entry  could  not  be  made,  the 
Logon  will  be  disabled. 

3.3.2  NTM  Communication  Services 

The  NTM  Communication  Services  are  those  that  process  the 
AP's  "mail"  requests.  There  are  five  basic  Communication 
Services  available:  NSEND,  I SEND,  QSEND,  RCV.  and  CHKMSG.  In 
addition.  TSTMOD  and  SIGERR  are  available  to  enable  the  send  and 
receipt  of  AP  error  messages.  The  AP  uses  NSEND  to  send  regular 
mail  or  data  to  other  IISS  APs  and  uses  ISEND  to  send  a  special 
request  to  start  a  specific  instance  of  an  AP.  A  queue-server 
AP,  however,  would  use  QSEND  instead  in  order  to  send  the 
message  directly  back  to  the  AP  from  which  the ’requesting 
message  was  received.  To  receive  messages  that  have  been 
delivered  to  the  AP,  the  AP  uses  RCV.  CHKMSG  is  the  service 
that  allows  the  AP  to  check  to  see  whether  it  has  reoeived  any 
mall.  If  the  AP  wishes  to  receive  AP  error  messages,  it  will 
call  TSTMOD  to  set  that  condition.  AP's  wanting  to  send  error 
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Messages  will  do  so  by  calling  SIGERR. 

The  logic  of  these  Conmunication  Services  is  described  in 
the  following  paragraphs. 

3.3.2. 1  MSEND 

The  primary  function  of  the  NTM  Service,  MSEMD.  is  to 
packet ise  the  data  supplied  by  the  calling  AP  in  an  MTM  message 
and  send  it,  via  the  local  MPU,  to  the  requested  destination. 

In  order  to  perform  this  function,  several  sxibtasks  must  be 
done .  These  tasks : 

•  Determine  the  number  of  message  packets  required 
(user  data  length  divided  by  the  maximum  message 
data  length  -  rounded  up). 

•  Formats  the  message  header . 

•  Send  the  message(s)  to  the  MPU  (SHDMSG). 

•  On  messages  that  require  an  acknowledgment  from  the 
MPU,  the  timer  ("SETTIM")  is  set,  a  receive  on  the 
ACK  mailbox  ("RCVMSG*)  is  issued,  followed  by  a 
wait  call  for  a  mailbox  or  timer  event  ("WAIT02"). 
On  a  mailbox  event,  the  message  ("GETMSG”)  is 
retrieved,  and  then  MSEMD  determines  whether  it  is 
an  acknowledgment  (Type  *MA“ )  or  HACK  (negative 
acknowledgment).  If  it  is  an  acknowledgment, 
processing  proceeds  by  either  returning  a 
successful  status  to  the  AP  or  returning  to  the 
message  formatting  task  to  send  the  remaining 
packets  for  the  user's  data.  A  MACK  oauses  a 

" message  no-accept”  status  to  be  returned  to  the 
user.  ACK  and  MACK  messages  are  sent  to  the  AP's 
ACK  mailbox  as  the  AP  will  only  read  the  ACK 
mailbox  at  this  time,  there  is  no  possibility  of  a 
buffer  overflow  prior  to  the  receipt  of  the  ACK  or 
MACK  Messages  that  may  arrive  at  this  time  are  sent 
to  the  AP's  hot  or  cold  mailbox  (or  queued)  for 
later  processing.  If  an  expected  acknowledgment  is 
not  received  within  a  specified  time  frame 
(RCV-WAIT) ,  the  AP  is  returned  an  unsuccessful 
MSEMD  status. 

There  are  several  bookkeeping  jobs  that  MSEMD  must  perform 
in  order  to  correctly  process  the  AP's  request.  These  are  the 
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fol lowing: 

•  Pairing  Logic  Support: 

The  NTM  Services  must  determine  the  correct  message 
category  for  the  message  header.  It  does  this 
according  to  the  following  logic. 

•  If  the  time-out  value  is  set  by  the  AP  in  the  NSEND 
calling  arguments  (non-zero),  a  paired  message 
(Category  'B")  is  indicated.  If  the  paired  request 
requires  continuation  messages,  only  the  first 
message  has  the  category  field  set  to  "B*.  All  the 
following  continuation  packets  for  this  request 
have  their  category  field  set  to  “unsolicited”  (E). 

•  If  the  message  is  not  a  paired  request,  NSEND  must 
determine  whether  the  message  is  a  response  to  a 
paired  message.  It  checks  the  services  global 
table.  RESPONSES -WAITING,  to  determine  if  the 
message  is  a  response  to  the  specified  destination 
on  the  channel  Indicted  in  NSEND 's  calling 
arguments.  The  RESPONSES-WAITING  table  is  filled 
by  the  RCV  service  when  it  receives  a  message  for 
the  AP  that  requires  a  response.  If  a  response 
entry  is  found  by  NSEND,  the  entry  is  deleted  from 
the  table  and  the  message  category  is  marked  as  a 
response  (category  E).  For  response  messages  with 
continuation  packets,  only  the  first  message  has 
its  category  field  set  to  response.  All  others  have 
their  category  set  to  "unsolicited"  (E). 

•  If  the  message  is  not  a  paired  request  or  a 
response,  the  category  field  is  set  to 
"unsolicited"  (E). 

•  Header  Formatting  Optimization 

To  optimize  the  number  of  message  acknowledgments 
required  for  AP  messages,  a  HEADER-BUFFER  that 
contains  headers  already  completed  and  accepted  by 
the  local  MPU  is  kept.  On  initiation,  NSEND  checks 
this  buffer  to  determine  whether  there  is  an 
accepted  header  with  the  designated  message  type 
for  the  specified  destination.  If  one  exists,  it 
is  used  to  format  the  messages  related  to  this 
current  NSEND  call.  A  header  field  that  signals 
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“old  header'  to  the  MPU  is  set.  This  disables  the 
acknowledgment  function  in  the  MPU  and  NSEND. 

For  continuation  messages,  only  the  first  message 
can  possibly  require  a  complete  new  header 
processing  ( FORMAT-NEW -MESSAGE-HEADER  paragraph) 
and  acknowledgment.  All  succeeding  messages  are 
marked  as  “old  headers'  and  no  acknowledgments  by 
the  MPU  are  required. 


3. 3. 2. 2  I SEND 

I SEND  is  a  special  purpose  'send  message'  service  that  is 
used  when  an  AP  specifically  wants  to  Initiate  a  new  instance  of 
an  AP.  It  differs  from  NSEND  in  one  area: 

•  1SEND  performs  the  same  categorization  logic  as 
NSEND  but  will  assign  category  "H“  (Specific 
Initiation)  or  category  “J"  (Specific  Initiation 
Response  Required)  based  upon  the  timeout  value  in 
the  calling  arguments. 

3. 3. 2. 3  QSEND 

QSEND  is  a  special  purpose  'send  message'  servioe  that  is 
used  when  an  AP  is  a  queue-server  and  therefore  must  repond 
specifically  to  a  message  already  received  from  some  particular 
AP  whose  name  data  has  been  saved  by  RCV.  It  differs  from  NSEND 
in  this  one  area: 

•  Routing  Data 

QSEND  participates  in  the  NTM  routing  function  by 
using  a  table  that  keeps  the  full  APC  names  of  APs 
from  which  it  has  received  messages  (RCV  fills  this 
table).  If  a  routing  entry  is  found  for  the 
destination  AP.  the  indicated  APC  name  and  the  APs 
instance  number  are  used  in  the  header  fields  for 
the  destination  information.  If  a  routing  entry  is 
not  found,  then  an  error  is  reported  as 
queue-servers  cannot  currently  respond  to  an  AP 
from  which  no  corresponding  message  was  received. 
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3. 3. 2. 4  RCV 

RCV  is  the  NTM  Service  used  by  all  IISS  APs  to  get  message 
data  that  has  been  sent  to  them  by  other  APs  and  the  NTM.  The 
RCV  CALL  has  the  following  format: 

CALL  “RCV’'  USING  LOG  I  CAL -CHANNEL , 

WAIT-FLAG, 

MSG-SOURCE . 

MESSAGE-TYPE, 

DATA-LENGTH , 

USER -DATA , 

ACCEPT -STATUS , 

MSG- SERIAL-NUMBER . 

The  input  arguments.  LOGICAL-CHANNEL.  WAIT-FLAG,  and 
MSG-SOURCE  determine  the  type  of  receive  requested  and  actually 
serve  to  partition  the  RCV  code.  LOGICAL-CHANNEL  and  MSG-SOURCE 
determine  the  type  of  message  requested  by  the  AP.  On  entry 
into  RCV,  a  variable,  MATCH-CRITERION,  is  set  to  ANY-M  (if  both 
LOGICAL-CHANNEL  and  MSG-SOURCE  are  not  set),  S-MATCH  (if 
MSG-SOURCE  only  is  set),  C-MATCH  (if  LOGICAL-CHANNEL  only  is 
set),  or  S-C-MATCH  (if  both  are  set).  If  WAIT-FLAG  is  set.  the 
RCV- AND- WAIT  paragraphs  are  executed.  Otherwise,  the 
RCV-AND-NOWAIT  paragraphs  are  executed. 

The  logic  of  RCV  is  the  following: 

•  Determine  the  message  MATCH-CRITERION  described 
above . 

•  Check  the  Service  global  buffer,  MSG-RCV -BUFFER . 
for  AP  messages  that  meet  the  MATCH -CR I TER I ON .  If 
there  is  a  message  in  the  buffer  that  meets  the 
MATCH-CRITERION,  the  correct  arguments  are  returned 
to  the  calling  AP.  The  value  of  ACCEPT-STATUS  is 
determined  by  the  message  category  and  the 
message-type  (if  the  source  of  the  received  message 
is  the  NTM). 

•  If  there  are  no  messages  in  the  buffer  that  meet 
the  MATCH-CRITERION,  perform  the  correct  RCV 
paragraph  (WAIT  or  NO-WAIT). 

•  The  number  of  RCV's  to  be  issued  is  based  on  a 
combination  of  the  calling  arguments  and  the  number 
of  mailboxes  the  AP  supports.  Therefore,  if  the  AP 
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supports  two  mailboxes  and  is  looking  for  any 
message,  a  RCV  will  be  set  on  both  the  hot  and  cold 
mailboxes.  Figure  3-10  provides  a  matrix  of  the 
combinations  to  show  the  number  of  RCV's  issued 
under  the  possible  conditions. 
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Figure  3- 

10.  RCV 

Condition  Matrix 

On  a  RCV-AND-NAIT,  the  correct  number  of  "RCV's* 
are  issued,  and  the  "VAIT01"  or  "VAIT02"  is  called 
to  set  a  wait  for  a  mailbox  event.  On  an  event, 
the  received  message  is  checked 

(CHECK-FOR-REQUESTED-MESSAGE)  to  determine  whether 
it  meets  the  HATCH-CRITERION.  If  the  message 
received  is  not  the  requested  message,  the  message 
is  stored  in  MSG-RCV- BUFFER  (paragraph 
PUT- IN-BUFFER ) .  This  step  is  repeated  until  a 
match  is  found  and  all  packets  belonging  to  the 
message  have  been  received.  Control  i6  then 
returned  to  the  calling  program. 

On  a  RCV-AND-NOWAIT,  "RCVMSG"  and  then  "GETMSG"  are 
issued  again,  based  on  the  conditions  for  hot.  cold 
or  both.  If  "no  message*  is  indicated  on  the 
"GETMSG*  return.  ACCEPT-STATUS  is  set  to  indicate 
"No-message”  and  oontrol  is  returned  to  the  calling 
AP.  Otherwise,  the  received  message  is  processed 
(CHECK -FOR -REQUESTED- MESS AGE)  in  the  same  manner 
described  in  the  RCV-AND-WAIT  paragraph  above.  The 
only  exception  is  that  the  receiving  prooess  is  not 
repeated  unless  the  message  indicates  a 
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continuation.  Then,  the  process  is  repeated  until 
all  the  packets  are  received.  If  the  received 
message  does  not  neet  the  match  criterion, 
ACCEPT-STATUS  is  set  to  indicate  "Mo-message" . 

e  When  a  message  is  about  to  be  returned  to  the 

caller,  the  return  arguments  an<*  any  necessary 
pairing  arguments  are  set.  Routing  information  is 
also  saved  because  if  the  calling  AP  is  a 
queue-server,  it  would  be  needed  for  a  QSEND  return 
message.  If  the  message  is  of  Category  B  or  J 
(Response-required),  the  response  information  is 
stored  in  the  RESPONSE-TABLE  (paragraph 
STORE-RESPONSE).  The  routing  table  is  searched 
(ROUTE-TABLE-TASK)  to  determine  whether  the  message 
source  has  an  entry.  If  one  already  exists, 
nothing  is  done.  If  one  does  not  exist,  an  entry 
is  made  in  ROUTING-TABLE  for  the  Source  AP.  This 
entry  consists  of  the  Source  AP  name,  its  APC  name, 
and  the  Source  AP's  instance  number.  It  will  be 
removed  when  QSEND  is  oalled  to  send  a  return 
message.  If  the  ROUTING-TABLE  fills  up,  which 
would  occur  if  we  are  not  a  queue-server,  we  simply 
do  not  add  any  more  entries  and  continue  since 
ROUTING-TABLE  entries  were  obviously  not  being  used 
anyway. 

3. 3. 2. 5  CHKMSG 

CHKMSG  is  the  NTH  Service  that  determines  whether  there 
are  messages  that  have  arrived  for  the  calling  AP.  Like  RCV, 
the  calling  AP  may  request  a  check  for  any  message,  a  message 
from  a  specific  source  on  any  channel,  one  from  any  source  but 
on  a  specific  channel ,  or  one  from  a  specific  source  on  a 
specific  channel.  All  that  is  returned  to  the  caller  is  the 
ACCEPT-STATUS  that  indicates  whether  or  not  a  message  of  the 
indicated  type  is  available;  the  message  itself  must  be 
retrieved  by  calling  RCV.  The  CHKMSG  call  has  the  following 
format : 


Call  "CHKMSG"  Using  Logical -Channel , 

Msg-Source , 

Ret -Code. 

Like  RCV,  the  buffer,  RCV-MSG-BUFFER ,  is  first  checked  to 
determine  if  there  are  any  messages  that  match  the  request 
criterion  of  the  call.  If  a  message  is  found  a  successful  status 
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Is  returned  to  the  calling  AP. 

If  there  is  no  message  in  the  receive  buffer  that  meets 
the  request  criterion,  “RCVMSG"  and  then  "GETMSG” ,  with  no  WAIT, 
are  called.  The  hot  mailbox  is  checked  only  if  the  AP  requested 
a  message  from  the  NTH  (by  specifying  MSG-SOURCE  as  “NTMPU” ) . 

The  AP's  mailboxes  are  read  until  a  message  that  meets  the 
request  criterion  is  found,  the  mailbox  is  empty,  or  the  global 
buffer  RCV-MSG-BUFFER  and  BUFFER -OVERFLOW -AREA  are  filled.  The 
AOCEPT-STATUS  return  to  the  calling  AP  will  indicate  the  CHKMSG 
status  —  either  “message  found*,  "no  message”,  or  “buffer 
overflow”.  Note  that  no  AP  messages  are  lost  on  a 
“buffer-overflow”  return.  The  last  message  is  stored  in  the 
overflow  area  and  the  condition  will  be  corrected  when  the  AP 
issues  a  RCV. 

3. 3. 2. 6  TSTMOD 

TSTMOD  is  the  service  that  sets  the  condition  for  an  AP's 
receipt  of  errror  meessages  from  its  child  APs.  The  AP  may 
choose  one  of  three  options:  Receive  all  error  messages; 
receive  only  fatal  error  messages ;or  receive  no  error  messages. 
When  called,  the  TSTMOD  service  will  set  the  appropriate  flag. 
Subsequent  error  messages  are  screened  in  accordance  with  the 
criteria  requested  by  the  AP  and  deliver  only  those  messages 
that  meet  the  criteria.  The  TSTMOD  call  has  the  following 
format:  Call  "TSTMOD”  using  Test  Status,  Ret  Code- 

3. 3. 2. 7  SIGERR 

SIGERR  allows  the  calling  AP  to  describe  an  error 
condition  to  its  parent  AP.  SIGERR  will  format  a  message  (type 
SE)  using  the  values  from  the  calling  arguments.  The  formatted 
message  is  sent  to  both  the  parent  AP  and  to  the  Monitor  AP. 

The  message  will  be  delivered  to  the  parent  AP  if  it  meets  the 
current  criteria  set  by  TSTMOD.  The  message  will  be  displayed 
to  the  ITSS  operator  if  SIGERR  is  enabled  (operator  command  SE). 
The  SIGERR  call  has  the  following  format: 

Call  “SIGERR”  using  ERROR-CODE, 

SEVERITY-LEVEL. 

ERROR -MES SAGE , 

RET -CODE . 
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There  are  three  NTM  Status  Messages  currently  available. 
These  are  CHGROL,  GETUSER  and  WHTHST.  CHGROL  is  used  by  the  UI 
to  inform  the  NTM  that  an  IISS  user  who  is  currently  logged  on 
has  changed  roleB.  GETUSER  is  called  by  the  AP  to  determine 
information  about  its  original  source.  WHTHST  is  used  to  find 
the  name  of  the  Host  Machine  upon  which  a  given  AP  currently 
resides.  These  services  are  described  in  the  following 
paragraphs . 

3.3.3. 1  CHGROL 

Like  LOGON  and  LOGOFF,  CHGROL  is  a  service  used  only  by 
the  Ul  to  inform  the  NTM  of  IISS  User  logon  information.  The 
call  format  is: 

Call  "CHGROL"  USING  TERMINAL-ID, 

USER-NAME , 

ROLE-NAME , 

RET -CODE . 


The  logic  is  identical  to  that  in  LOGON  and  LOGOFF.  It 
involves  a  simple  message  formatting  procedure  that  fills  in  the 
message  structure  for  the  CHGROL  message  contained  in 
CHGMSG . INC .  After  the  message  formatting  procedure  is  complete, 
CHGROL  sends  the  message  to  the  monitor  on  the  primary  host  via 
the  local  NTM. 

3. 3. 3. 2  GETUSER 

GETUSR  is  the  NTM  Service  called  by  an  AP  when  it  needs  to 
know  specific  data  about  it's  original  source.  This  need  may 
arise  when  an  AP  is  part  of  a  chain  and  wants  to  send  a  message 
to  the  originator  of  the  chain.  It  can  also  occur  when  an  AP, 
as  in  the  case  of  MCMM,  needs  to  know  logon  data  regarding  the 
user  who  started  the  chain  for  database  access  control . 

The  GETUSR  CALL  is: 

Call  "GETUSR"  USING  R-APNAME, 

LOGICAL-CHANNEL, 

USER-NAME, 

ROLE -NAME , 

TERM-ID, 

RET -CODE . 

The  global  section  of  the  Services  contains  the  original 
source  AP  data.  The  user's  logon  data  is  kept  in  the  Logon 
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table  which  is  maintained  by  the  Monitor  AP.  This  logon  data  is 
only  required  if  the  original  source  i6  the  UI  (a  user  at  a 
terminal  serviced  by  the  UI).  The  logic  of  GETTJSR  then: 

e  First  determines  whether  the  original  source  of  the 

AP  i6  the  DI.  If  not,  the  R-AP-NAME  and 
LOGICAL-CHANNEL  return  arguments  are  set  with  the 
correct  values  and  the  user  data  argument  are  set 
to  blanks.  The  return  values  are  then  given  to  the 
calling  AP. 

•  If  the  original  source  AP  is  the  UI,  a  message 

requesting  the  user  logon  information  is  sent  to 
the  VAX  Monitor  AP.  The  service  NSEND  is  used  here 
with  the  message  type  set  to  "UX"  to  indicate  the 
GETUSR  data  request . 

Following  a  successful  NSEND,  a  RCV  (with  wait)  is 
issued  for  the  response  message  from  the  Monitor. 

On  a  successful  return  from  RCV,  the  user  data  is 
returned  to  the  calling  AP. 


3. 3. 3. 3  WHTHST 

WHTHST  is  used  by  any  AP  wishing  to  know  the  host  location 
of  itself  or  any  other  AP  in  the  XISS.  The  call  format  is: 

Call  "WHTHST"  USING  AP-NAME 

AP-HOST-NAME 

RETURN-STATUS 


If  the  AP-NAME  argument  is  blank,  the  service  will  assume 
that  the  request  is  for  the  calling  AP's  location.  The  service 
will  format  a  message  to  the  local  MPU  requesting  the  host  name 
of  the  given  AP.  The  local  MPU  will  process  the  request  by 
searching  the  tables.  If  the  given  AP  is  found,  it's  host  name 
is  returned.  If  it  is  not  found,  a  status  message  to  that 
effect  will  be  returned.  The  WHTHST  service  will  interpret  the 
message  from  the  MPU  and  return  the  information  to  thecal  ling 
AP. 

» 

As  in  the  GETUSR  service,  WHTHST  uses  the  "NSEND”  and 
"RCV"  services  for  it's  dialog  with  the  MPU. 
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3.3.4  MTM  Termination  Services 


The  NTM  Termination  Servioes  are  used  to  signal  the  end  of 
an  IISS  user  session  to  the  NTM  (LOGOFF)  or  the  end  of  an  AP'6 
IISS  processing  (TRMNAT).  These  two  services,  LOGOFF  and 
TRMNAT.  are  described  in  the  following  paragraphs. 

3.3.4. 1  LOGOFF 

LOGOFF,  like  LOGON  and  CHGROL,  is  used  by  the  UI  to  inform 
the  NTM  of  an  IISS  user's  logon  status.  When  an  IISS  user 
terminal  logoff  has  been  received  by  the  UI,  it  informs  the  NTM 
of  the  event  with  a  call  to  LOGOFF.  The  LOGOFF  call  syntax  is 

Call  "LOGOFF"  USING  TERMINAL-ID, 

USER-NAME . 

ROLE -MAKE , 

RET -CODE . 

The  LOGOFF  routine  uses  the  three  input  argument  values  to 
format  the  LOGOFF  message  (LGFMSG. INC)  which  is  then  sent  to  the 
primary  Monitor  (currently  the  VAX)  via  the  local  MPU. 

3. 3. 4. 2  TRMNAT 

All  IISS  APs  use  the  NTM  service,  TRMNAT,  to  terminate 
their  connection  to  the  IISS.  The  TRMNAT  call  syntax  is: 

Call  "TRMNAT"  USING  TERMINATION-STATUS. 

TRMNAT  has  the  following  three  major  tasks. 

•  Informs  the  local  MPU  that  the  AP  is  terminating. 
TRMNAT  does  this  by  sending  an  "I'm  Dying"  message 
to  the  MPU.  The  format  of  this  message  is  in  the 
include  file  ADMSGH. INC. 

•  Deletes  the  AP's  mailboxes  by  callilng  the  IPC 
"DELMBX*  for  each  AP  mailbox. 

•  Stops  the  AP's  processing  with  a  call  to  the  IPC, 
"ENDRUN",  which  for  the  VAX  issues  the  STOP  RUN  for 
the  AP. 
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3.S.4.3  TRMNAX 


TRMNAX  terminates  COMM'S  connection  to  the  IISS.  Since 
COMM  deletes  its  input  mailbox,  TRMNAX  has  only  two  functions: 
send  the  aAP  DYING"  message  to  the  OOMM  APC  and  then  call 
“ ENDRUN "  to  terminate  the  AP. 

Call  "TRMNAX"  USING  USER-TERMINATE-STATUS , 

MPU- INSTANCE. 

3-3.5  NTM  Service  Error  Handling 

Most  errors  occuring  wi thing  the  NTM  services  cause  a  call 
to  ERRPRO ,  which  puts  an  error  message  in  ERRLOG.  Service 
routines  that  terminate  processes  (e.g.,  TRMNAX)  will  then  stop 
the  application:  other  service  routines  will  return  to  the 
application  with  a  5-digit  return  indicating  the  type  of  error. 

3.4  NTM  Internal  Table  Access  and  Control 


The  NTM  tables  provide  both  static  configuration  and 
dynamic  operating  data.  This  data  is  continually  accessed  by 
the  NTM  components  for  routing,  processing,  and  various 
bookkeeping  functions.  The  table  functionality  and  content  is 
discussed  in  detail  in  the  NTM  Development  Specification  [1]. 
Structure  Charts  and  Module  descriptions  of  the  table  routines 
are  available  in  the  NTM  Product  Specification,  Vol.  3  [2]. 

The  table  handling  routines  consist  of  two  generic  types: 
initialization  and  access.  Within  these  types,  the  static  and 
dynamic  tables  are  handled  differently.  The  table 
initialization  routines  for  static  tables  are  called  during 
start-up  processing  to  load  static  data  into  memory.  This 
static  data  provides  the  basic  system  configuration  information 
such  as.  the  location  of  APs  within  the  IISS,  the  initial  status 
of  the  APCs  and  hosts,  and  processing  requirements  of  the 
various  message  categories.  When  called,  the  initialization 
routines  will  open  the  appropriate  file,  read  the  existing 
records  into  memory,  and  close  the  file.  Each  static  table 
initialization  routine  follows  the  same  logic:  the  only 
difference  between  them  is  the  file  which  is  accassed. 

The  dynamic  table  Initialization  routines  serve  to  clear 
out  spaoe  in  memory  sufficient  to  hold  the  number  of  records 
mandated  by  the  occurs  clause  in  the  table  description. 

The  table  access  routines  provide  the  functionality  for 
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reading,  writing,  modifying,  and  deleting  records.  The  oalling 
arguments  specify  the  table  to  be  aocessed,  the  function  to  be 
performed  on  the  table,  a  search  field  and  value  (if  needed),  a 
search  start  flag,  an  index  (if  known),  and  a  record  buffer. 
Based  on  the  given  parameters,  the  routine  will  perfo*  .  -he 
requested  function.  Each  routine  follows  the  same  basic  logic, 
again  with  different  handling  for  static  and  dynamic  tables.  As 
with  the  initialization  routines,  the  major  difference  is  the 
table  which  is  accessed. 

The  following  is  a  list  of  the  functions  provided  by  the 
'Table*  access  and  control  routines: 

•  RS  -  Read  Search 

•  RA  -  Read  All 

•  VT  -  Write  New 

•  HD  -  Modify  Old 

•  DI  -  Delete  Index 

The  Dynamic  Table  routines  perform  all  of  the  above 
funtionality.  They  will  attempt  to  use  in-core  memory  by 
re-using  space  left  by  deleted  entries.  Where  all  the  in-core 
space  is  occupied,  these  routines  will  acoess  files.  These 
files  are  organized  in  Index-Sequential  format  with  the  local 
APC  name  as  part  of  the  primary  key.  The  exception  to  this  is 
the  Logon  Table  which  is  organized  sequentially  (as  it  is 
accessed  only  by  the  monitor  AP). 

The  static  tables  are  also  resident  in  memory.  If  needed, 
file  access  calls  will  check  records  kept  on  disk.  The  static 
table  routines  contain  all  the  functionality  described  above  but 
the  write  and  delete  functions  are  not  currently  u';ed. 

Table  initialization  routines  are  named  "xxxINI "  where 
"xxx"  is  the  abbreviation  for  the  specific  table  being 
initialized  (6uch  as  'CAT"  for  the  message  category  table  - 
"CATINI " ) .  Using  the  same  convention,  the  access  routines  are 
named  "xxxTBL"  where  "xxx’'  is  the  abbreviation  for  the  table 
being  accessed  (message  category  table  -  * CATTBL " ) .  The  static 
configuration  data  is  contained  in  files  which  follow  the  naming 
convention  "xxxTBL.DAT"  where  "xxx"  is  the  abbreviation  for  the 
specific  table  to  be  initialized  (such  as  "CAT”  for  the  message 
category  table  "CATTBL.DAT").  Each  table  is  described  in  an 
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include  file  named  according  to  the  convention  "TBLXXX.  Inc." 
where  xxx  is  the  table  name. 
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SECTION  4 
DATA  STRUCTURES 


4 . 1  Sysgen  Data  Processing 

Certain  data  items  (formerly  contained  in  the  include 
files  INTMON  and  STEVB,  among  others)  have  been  brought  together 
in  one  file  that  is  read  by  both  the  Monitor  AP  and  each  MPU  at 
startup.  This  file  contains  those  data  items  that  (a)  are 
subject  to  change  and  (b)  should  not  be  hard  coded. 

The  data  file  that  is  read  at  startup  is  called 
SYSGEM.DAT.  The  structure  of  the  data  items  in  this  file  are 
shown  in  Figures  4-1  and  4-2.  The  structure  Is  described  in 
BASYSG.  INC.  The  value  of  these  items  may  be  modified  by 
running  the  routine  MPUGEN.  This  routine  provides  the  user  with 
the  main  options  shown  below. 

SYSGEN  OPTIONS  AVAILABLE: 

1.  CREATE  DEFAULT  SYSGEN  FILE 

2.  CREATE  NEW  IISS  SYSGEN  DATA  RECORD 

3.  MODIFY  EXISTING  IISS  SYSGEN  DATA  RECORD 

4.  CHANGE  IISS  INSTANCE 

5.  MODIFY  EXISTING  APC  DATA  RECORD 

6.  DELETE  EXISTING  APC  DATA  RECORD 

7.  ADD  NEW  APC  DATA  RECORD 

8  -  QUIT 

PLEASE  ENTER  NUMBER  OF  YOUR  CHOICE 

The  offered  options  are  described  below. 

•  CREATE  DEFAULT  SYSGEN  FILE 

This  option  uses  the  default  initial  sysgen 
parameters  contained  in  BASYSG.  INC.  (Figures  4-1 
and  4-2)  to  create  an  initial  SYSGEN.DAT  file  with 
all  messsage  serial  number  seeds  at  0.  Note  that 
any  value  modified  via  MPUGEN  may  be  lost  if  it  is 
not  also  modified  in  BASYSG.  The  include  member 
holds  all  system  default  values  as  opposed  to 
values  as  "tuned.”  If  a  new  default  value  is 
defined,  it  must  be  included  in  BASYSG. 
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*  MONITOR'S  DEFAULT  SYSGEN  DATA 


01  REC-1 . 


05 

HEADER -REC-1 

PIC  X( 15 ) 

VALUE 

*  MTRSYGENLOCALS " 

05 

IISS-ID 

PIC  X 

VALUE 

"A"  . 

05 

INIT-HOST-NAME 

PIC  X(3) 

VALUE 

■VAX" . 

05 

INIT-APC-NAME 

PIC  X(3) 

VALUE 

■MRV* . 

05 

INIT-MPU-NAME 

PIC  X(10) 

VALUE 

■ NTNTMRVMPU " . 

05 

INIT-COM-APC 

PIC  X( 3) 

VALUE 

"COV"  . 

05 

INIT-UI -APC 

PIC  X(3) 

VALUE 

■UIV“ . 

05 

INIT-BASEPRI 

PIC  X(2) 

VALUE 

“00“  . 

05 

INIT-PROC-TYPE 

PIC  X 

VALUE 

“M"  . 

05 

IN I T-MODULE-NAME 

PIC  X(10) 

VALUE 

“NTNTMONITV “ . 

05 

INIT-TIMER-DELAY 

PIC  X(6) 

VALUE 

"000500" . 

05 

INIT-TABLE-STATUS 

PIC  X 

VALUE 

"0"  . 

05 

INIT-LINK -COUNT 

PIC  X 

VALUE 

"1"  . 

* 

05 

FILLER -REC-1 

PIC  X(26) 

VALUE 

SPACES . 

01 

REC-2 

05 

HEADER-REC-2 

PIC  X( 15) 

VALUE 

" MTRS YSGENHSTLNK 

05 

LINKID 

PIC  X(2) 

VALUE 

"VH"  . 

05 

COMMAP 

PIC  X(10) 

VALUE 

" COCOMVHCOM " . 

05 

HSTNAM 

PIC  X(3) 

VALUE 

"HL6" . 

05 

MTRNAM 

PIC  X(10) 

VALUE 

" NTNTMONITH " . 

05 

MTRAPC 

PIC  X(3) 

VALUE 

"MRH" . 

05 

NODE 

PIC  X 

VALUE 

"0"  . 

• 

05 

FILLER-REC-2 

PIC  X(41) 

VALUE 

SPACES . 

01 

REC-3 

05 

HEADER- REC-3 

PIC  X(15) 

VALUE 

" MTRS Y SGENHSTLNK 

05 

LINKID 

PIC  X(2) 

VALUE 

"VI"  . 

05 

COMMAP 

PIC  X(10) 

VALUE 

"COCOMVCOMI " . 

05 

HSTNAM 

PIC  X(3) 

VALUE 

"IBM" . 

05 

MTRNAM 

PIC  X(10) 

VALUE 

"NTNTMONITI " . 

05 

MTRAPC 

PIC  X( 3) 

VALUE 

"MRI " . 

05 

MODE 

PIC  X 

VALUE 

"0"  . 

05 

FILLER-REC-3 

PIC  X(41) 

VALUE 

SPACES . 

Figure  4-1.  Monitor's  Sysgen  Data 
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*  MPU'S  DEFAULT  SYSGEN  DATA 

01  IISS-SYSGEN-DATA. 

05  I I SS -HEADER 
05  ID-HOSTNAME 
05  ID-LOCMTR 
05  ID-MSTRMTR 
05  ID-LOCMTR-APC 
05  ID-MSTRMTR -A PC 
05  ID-CDMAPC 
05  ID-GOMMAPC 
05  Q- INDICATOR 
05  MAX-NO-QUEUED 
05  MAX-LAST-KEY 
05  COM-LOG-INDICATOr 
05  LOCAL-MBX-SIZE 
05  ST-TIME-CHECK- INTERVAL 
05  TIME-CHECK- INTERVAL 
05  NUM-WRITE-TRIES 
05  IAT-MAX-NUM-TRIES 
05  I I SS- INSTANCE 

01  MRV-SYSGEN-DATA 
05  MPU-HEADER 
05  ID-APCNAME 
05  ID-MSGSN 
05  MPU-FILLER 

* 

01  CDM-SYSGEN-DATA 
05  MPU-HEADER 
05  ID-APCNAME 
05  ID-MSGSN 
05  MPU-FILLER 

* 

01  UIV-SYSGEN-DATA 
05  MPU-HEADER 
05  ID-APCNAME 
05  ID-MSGSN 
05  MPU-FILLER 


PIC 

x(9) 

VALUE 

“HSTSYSGEN" . 

PIC 

X(  3) 

VALUE 

“VAX" . 

PIC 

X(10) 

VALUE 

“HTNTMONITV* 

PIC 

X(10) 

VALUE 

“NTNTMONITV" 

PIC 

X(  3) 

VALUE 

"MRV“. 

PIC 

X(  3) 

VALUE 

“MEV" . 

PIC 

X(  3) 

VALUE 

“CDM" . 

PIC 

X(3) 

VALUE 

“COV“ . 

PIC 

X 

VALUE 

-o- . 

PIC 

X(4) 

VALUE 

<aOOOQN 

PIC 

X(9) 

VALUE 

*999999999' . 

PIC 

X 

VALUE 

"0"  . 

PIC 

X(5) 

VALUE 

*02100“ . 

PIC 

X(6) 

VALUE 

“000100" . 

PIC 

X(6) 

VALUE 

“000100“ . 

PIC 

X(4) 

VALUE 

“0020“ . 

PIC 

X(4) 

VALUE 

“0003" . 

PIC 

X 

VALUE 

“A"  . 

PIC 

X(9) 

VALUE 

“MPUSYSGEN" 

PIC 

X(3) 

VALUE 

“MRV* 

PIC 

X(7) 

VALUE 

“0000000" . 

PIC 

X(66) 

VALUE 

SPACES . 

PIC 

X(9) 

VALUE 

“MPUSYSGEN" 

PIC 

X(3) 

VALUE 

“CDM" . 

PIC 

X(7) 

VALUE 

"0000000“ . 

PIC 

X(66) 

VALUE 

SPACES . 

PIC 

X(9) 

VALUE 

“MPUSYSGEN" 

PIC 

X(3) 

VALUE 

"UIV“ . 

PIC 

X(7) 

VALUE 

"0000000" . 

PIC 

XC66) 

VALUE 

SPACES . 

Figure  4-2.  MPU's  Sy6gen  Data 
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* 

01  GOV -SYSGEN -DATA 
05  MPU -HEADER 
05  ID-APCNAME 
05  ID-MSGSN 
05  MPU-FILLER 

* 

01  T1V-SYSGEN-DATA 
05  MPU -HEADER 
05  ID-APCNAME 
05  ID-MSGSN 
05  MPU-FILLER 


PIC  X(9) 

VALUE 

"MPUSYSGEN" 

PIC  X(3) 

VALUE 

“COV" . 

PIC  X(7) 

VALUE 

“ 0000000  * 

PIC  X(66) 

VALUE 

SPACES. 

PIC  X(9) 

VALUE 

"MPUSYSGEN" 

PIC  X(3) 

VALUE 

"T1V" . 

PIC  X(7) 

VALUE 

"0000000" . 

PIC  X(66) 

VALUE 

SPACES . 

Figure  4-2.  KPO's  Sysgen  Date  (Continued) 
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•  CREATE  NEW  IISS  SYSGEN  RECORD 

This  option  will  replace  the  ZISS  Sysgen  record  in 
SYSGEN.DAT  with  a  new  record  which  i6  built  by 
prompting  the  user  for  the  new  values  for  certain 
fields  in  the  IISS  sysgen  record  (as  listed  in 
Figure  (4-3)).  The  IISS  instance  identifier  is  not 
changed  in  this  option. 

e  MODIFY  EXISTING  IISS  SYSGEN  RECORD 

This  option  will  replace  the  IISS  sysgen  record  in 
SYSGEN.DAT  with  a  new  record  which  is  built  by 
prompting  the  user  for  the  new  values  for  certain 
fields  in  the  IISS  sysgen  record  whioh  the  user 
wishes  to  modify.  The  user  has  the  option  of 
changing  some  values  while  leaving  others  as 
defined . 

•  CHANGE  IISS  INSTANCE 

This  option  allows  the  user  to  change  the  IISS 
instance  value  in  both  the  monitor  sysgen  record 
and  the  MPU  sysgen  record. 

•  MODIFY  EXISTING  APC  DATA  RECORD 

This  option  allows  the  modification  of  the  message 
serial  number  seed  in  the  APC  sysgen  data  record. 

•  DELETE  EXISTING  APC  DATA  RECORD 

This  option  deletes  the  APC  sysgen  data  record  for 
a  selected  APC. 

•  ADD  NEW  APC  DATA  RECORD 

This  option  allows  the  user  to  add  a  new  APC  sysgen 
data  record  to  the  sysgen  file. 

•  QUIT 

Writes  any  modified  values  to  SYSGEN.DAT  and  exits 
MPUGEN . 
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Host  Name 

Local  Monitor  AP  Name 
Master  Monitor  AP  Name 
Local  Monitor's  APC  Name 
Master  Monitor's  APC  Name 
CDM  APC  Name 
COMM  APC  Name 
Queue  Indicator 
Maximum  Number  Queued 
Max  Last  Key 
COMM  Log  Indicator 

Local  Mailbox  Size  (sets  the  sine  of  all  mailboxes) 

Startup  Time  Check  Interval  (Monitor  AP  Timer) 

Timer  Interval  (MPU  Timer) 

Number  of  Write  Tries  (number  of  times  the  MPU  will 

attempt  to  write  to  a  full  mailbox) 

IAT  Max  Number  of  Tries  (number  of  times  an  I'm  alive 

entry  will  be  checked  before 
concluding  that  the  AP  did  not 
initiate) . 

Figure  4-3.  SYSGEN  Data  Items  Modified  or  Added  via  MPUGEN 


4-6 


SUM620 142000 
1  November  1985 


The  use  of  this  routine  allows  the  ZZ8S  operator  to  set 
runtime  values  of  the  data  items  noted  in  Figure  4-3.  Zn 
addition,  the  ZZSS  instance  ZD  Bay  be  modified  in  order  to  run 
multiple  ZZSS  images  at  one  time.  Any  ohanges  made  beoome 
effective  during  the  next  execution  of  the  start  ZZSS  oommand. 
Mo  recompilation  is  necessary. 

4.2  Monitor  Application  Prooess 

4.2.1  Monitor  AP  Internal  Table 


The  Monitor  AP  has  a  special  internal  table,  oalled  the 
Host-Link  Information  Table  (KLT).  which  provides  information 
regarding  remote  ZZSS  hosts,  the  oomm  links  to  coamunioate  with 
these  remote  hosts,  and  the  remote  monitor  APs.  This  table  is 
maintained  as  part  of  the  Sysgen  paraaenters  and  is  read  into 
the  Monitor  AP  during  startup.  When  a  new  host  is  introduced 
into  the  ZZSS  environment,  a  new  entry  must  be  made  in  this 
table.  This  is  currently  accomplished  by  manually  editing  the 
lnolude  file  BASYSG  and  the  routine  MTRGEM .  BASYSK  will  be 
expanded  to  contain  the  new  host  data  while  MTRGEM  will  move  the 
new  record  into  the  data  file.  The  Host  Link  table  entries  are 
described  in  REC-2  and  REC-3  in  Figure  (4-1).  The 
ZMZT-LZNK-OOUMT  Value  in  REC-1  will  also  have  to  be  modified  to 
reflect  the  correct  number  of  links  to  remote  host6  that  must  be 
established  at  startup. 

4.3  Message  Processing  Pnlt 

During  ZZSS  start-up  the  MPU  uses  APC  Initialization  data 
which  is  contained  in  an  internal  data  structure  called  "ZDATA" . 
At  runtime,  the  MPU  uses  various  queues  in  its  operation.  These 
data  structures  are  described  below. 

4.3.1  Queues 

4. 3. 1.1  Off-Cluster  Message  Queue 

Messages  destined  for  an  off-cluster  AP  that  oannot  be 
delivered  immediately  are  written  sequentially  to  a  file.  This 
file  serves  as  the  off-cluster  message  queue.  Periodically,  the 
MPU  process  this  queue  by  reading  and  delivering  each  message  in 
f irst-in-f irst-out  order. 
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4.S.1.2  On-Cluster  Message  Queue 

Messages  destined  for  application  processes  on  the  cluster 
that  cannot  be  delivered  immediately  are  written  sequentially  to 
a  file.  This  file  serves  as  the  on-cluster  message  queue. 
Periodically,  the  MPU  processes  this  queue  by  reading  and 
delivering  each  message  in  first-in-first-out  order  (for  each 
AP). 


4.5.2  A PC  Initialisation  Data 


During  the  start-up  of  an  AP  cluster,  the  MPU  reads  the 
STSGEM  data  file  to  obtain  it's  local  operating  data.  This 
information  is  then  stored  in  the  data  structure  IDATA.  The 
MPU's  process  name  is  determined  by  calling  the  MTM  service, 
GETNAME,  and  is  also  stored  in  IDATA.  The  data  structure  IDATA 
is  defined  in  INIDAT.INC  and  is  passed  to  every  MPU  sub-routine. 


01  IDATA 

03  IDATA-DAT. 

05  ID-APCNAME 
88 
88 
88 
88 
88 
88 
88 
88 
88 
88 

05  ID-MSGSM 
05  ID-HOSTNAME 
05  ID-LOCMTR 
05  ID-MSTRMTR 
05  ID-LOCMTR -A PC 
05  ID-MSTRMTR- APC 
05  ID-CDMAPC 
05  ID-COMMAPC 
05  Q- INDICATOR 

88  ONE -MPU -ONLY 
88  DO-ALL 
05  MAX-NO-QUEUED 
05  MAX-LAST-KEY 
05  COM-LOG- INDICATOR 
05  LOCAL-MBX-SIZE 
05  ST -TIME-CHECK- INTERVAL 


PIC  X(3) . 

VALUE  *COV" . 
VALUE  •001“ . 
VALUE  “COH" . 
VALUE  “MRI " . 
VALUE  "MRV" . 
VALUE  “MRH“ . 
VALUE  “UIV. 
VALUE  "T1V" . 
VALUE  “T1H" . 
VALUE  “CDM-. 

PIC  X(7) . 

PIC  X(3). 

PIC  X(10). 

PIC  X(10). 

PIC  X(3) . 

PIC  X( 3) . 

PIC  X(3). 

PIC  X(3). 

PIC  X. 

VALUE  •1“. 
VALUE  "0". 

PIC  9(4). 

PIC  9(9). 

PIC  X. 

PIC  9(5). 

PIC  9(6). 


VAX -COMM 

IBM -COMM 

HWL-COMM 

IBM-MTR 

VAX-MTR 

HVL-MTR 

TMP-UI 

VAX-TESTAP 

HWL-TESTAP 

CDM-AP 
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05  TIME-CHECK- INTERVAL 
05  MUM-WRITE-TRIES 
05  I AT-MAX -MUM-TRIES 
05  IXSS-XMSTANCE 
03  ID-MPU-PROC-MAME. 

10  MPU-PREFIX 

10  MPU-APMAME 

10  MPU-PART 

10  MPU-IMST 

03  Q-TABLE. 

05  MAX-XM-Q-TABLE 
05  MO-IH-Q-TABLE 
05  CLQTBL  OCCURS  10  TIMES. 

10  CLQ-APCNAME 
10  CLQ-NUMMSG 
10  CLQ-LASTKEY 
03  ACK-FLAG 

88  YES-ACK  VALUE 

88  MO-ACK  VALUE 

03  UIAPMAME 

4.4  HTM  Internal  Tables 

During  its  operation,  the  NTM  maintains  seventeen  internal 
tables  (see  Figure  4-4).  These  tables  contain  static  data, 
dynamic  data,  or  a  combination  of  both.  Figure  4-5  identifies 
the  tables  as  members  of  these  categories. 

Static  tables  are  those  whose  records  are  fixed.  These 
records  are  read  by  the  NTM  components  but  not  changed  during 
IXSS  operation.  These  tables  are  initialized  at  start-up. 

Dynamic  tables  are  those  whose  records  are  created  and 
used  only  during  system  operation.  At  start-up,  these  tables 
initialized  as  empty  space. 

Static/Dynamic  tables  are  those  whose  records  include 
items  whose  values  are  changed  during  system  operation.  These 
tables  are  initialized  at  start-up  with  the  dynamic  values  set 
for  start-up  conditions. 

The  IXSSCLXB  copy  library  contains  a  member  for  each 
table.  These  copy  members  specify  the  Internal  description  of 
each  table  in  COBOL  syntax. 

The  tables  are  further  defined  as  being  global  or  local  as 
follows : 
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PXC  9(6). 

PIC  9(4). 

PXC  9(4). 

PIC  X. 

PXC  X(2) . 

PXC  X(5) . 

PIC  X(3). 

PXC  XX. 

PXC  9(4). 

PIC  9(4). 

PIC  X(3) 

PXC  9(4) 

PIC  9(9). 

PIC  X. 

•1"  . 

“0“  . 

PIC  X(8)  VALUE  “TSPUIMPU" . 
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•  Global  tables  are  those  that  are  known  to  all  NTH 
components  on  one  specific  host  (such  as  the  VAX). 
There  exists  only  one  copy  of  this  type  of  table 
and  it  is  contained  in  the  system-wide  shared 
('global*)  memory. 

•  Local  tables  are  those  that  are  known  only  to  a 
specific  AP  Cluster  (suoh  as  the  monitor  MPU). 

Only  one  copy  of  this  table  will  exist  on  any  one 
AP  cluster  and  it  will  be  contained  within  the  AP 
cluster's  shared  memory. 

In  either  case,  access  to  the  tables  is  provided  by  the 
NTH  table  access  routines,  which  are  described  in  Section  3.4  of 
this  document.  These  internal  tables  are  never  accessed 
directly,  only  through  the  use  of  the  NTH  table  acoess  routines. 
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Figure  4-4.  WTM  Tables  -  Overview  (Continued) 
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SECTION  5 

HOST  SYSTEM  DEPENDENT  SPECIFICS 


5.1  Introduction 

There  are  &  set  of  functions  required  by  the  MTM  whose 
implementations  are  host  system  dependent.  These  functions  have 
been  isolated  in  routines  that  will  have  the  same  high  level 
calls  on  all  of  the  IISS  hosts.  These  routines  are: 

•  ASCTIM  Returns  the  host  system  time  as  an  ASCII 

string. 

•  CGSHST  Creates  the  global  memory  section  that 

contains  tables  shared  by  all  the  APCs  and 
the  monitor  on  a  host. 

•  CRTPRC  Creates  an  instance  of  an  IISS  AP. 

•  DELPRC  Deletes  a  particular  instance  of  an  IISS  AP. 

•  GETNAM  Returns  the  process  name  given  to  an  AP  by 

the  NTH.  This  name  is  used  to  form  an  APs 
mailbox  name. 

•  GETTIM  Returns  the  system  time  as  a  binary  string. 

•  MAPHST  Called  by  an  MPU  to  map  to  the  host's  global 

sect i on . 

These  routines  logically  fall  into  the  following  three 
categories:  process  control  related  routines  ( CRTPRC ,  DELPRC, 
GETNAM),  global  memory  routines  (CGSHST,  MAPHST),  and  host 
system  time  requests  (ASCTIM,  GETTIM).  The  VAX  implementations 
of  these  modules  are  described  in  the  following  subsection. 

While  the  table  acoess  routines  do  not  directly  use 
operating  system  calls,  they  may  have  some  system  dependency  in 
the  file  access  related  oode  and  should  also  be  considered  as  a 
part  of  this  section. 
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5.2  VAX  Implementation  of  System  Dependent  Modules 

5.2.1  Process  Control  Modules 

5. 2. 1.1  CRTPRC 

CRTPRC  is  the  module  used  by  the  NTH  to  create  a  new 
Instance  of  an  XISS  AP.  On  the  VAX.  the  VMS  high  level  language 
operating  system  call  "SYSSCREPRC"  is  used.  The  call  currently 
has  the  following  structure: 

CALL  "SYSSCREPRC"  USING  BY  REFERENCE  PROCESS-ID 

BY  DESCRIPTOR  IMAGE 
BY  DESCRIPTOR  EQUIVNAME 
BY  DESCRIPTOR  EQUIVNAME 
BY  DESCRIPTOR  EQUIVNAME 
BY  VALUE  0.0 
BY  DESCRIPTOR  PRONME 
BY  VALUE  BASE-PRIORITY 
BY  VALUE  0 
BY  VALUE  0 

BY  VALUE  STATUS -FLAG 
GIVING  SS-STATUS. 

The  descriptions  of  the  arguments  are  in  the  VMS  System 
Services  Manual  |5].  The  call  is  currently  set  up  to  run  the 
created  process  as  a  subprocess  of  the  NTM  (the  tenth  argument 
set  to  zero  gives  a  subprocess). 

To  create  detached  processes,  this  10th  zero  should  be 
replaced  by  UIC-LONG  and  the  correct  VAX  UXC  placed  in  this  data 
item  (see  RTPRD. INC) .  Also,  the  three  EQUIVNAME  entries  in  the 
call  should  be  replaced  by  zeros.  EQUIVNAME  allows  the 
subprocess  to  communicate  with  the  terminal  associated  with  the 
parent  process.  EQUIVNAME  is  obtained  by  a  prior  call  to 
SYSITRNLOG"  on  SYSSGOMMAND  which  gives  the  equivalence  name  for 
SYSSCOMMAND.  On  startup  of  the  NTM,  an  assignment  of 
SYSSGOMMAND  to  the  current  terminal  completes  this  process  [5]. 
This  was  useful  for  debugging  in  the  development  stages  of  the 
NTM. 


The  seventh  argument,  currently  zero,  is  for  assigning 
quotas  to  created  process.  This,  with  the  BASS-PRIORITY 
argument,  might  be  looked  at  as  a  settable  argument  when 
performance  evaluation  is  considered. 
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5. 2. 1.2  DELPRC 

The  delete  process  routine,  DELPRC,  is  called  by  the  MPDs 
and  is  implemented  by  using  the  VAX  operating  system  call 
"SYSIDELPRC"  as  shown  below. 

CALL  *SYS$DELPRC”  USING  BY  VALUE  0 

BY  DESCRIPTOR  PROMME 
GIVING  SS-STATUS. 

PRONME  is  the  process  name  indicated  by  the  MPU's  call  to 
DELPRC : 

CALL  DELPRC  USING  PRONME. 

NTH-RETURN, 

SS-STATUS . 

The  first  argument  indicates  the  process  ID.  By  setting 
this  to  zero,  VMS  uses  the  process  name  (PRONME)  to  find  the 
indicated  process. 

5. 2. 1.3  GETHAM 

GETMAM  finds  the  calling  AP’s  process  name  by  using  the 
VMS  "GET  JOB  Process  Information11  call  (SYSSGETJPI) . 

A  data  structure  ITEM-LIST  is  constructed  as  follows  to 
indicate  that  only  the  process  name  information  is  required. 

WORKING-STORAGE  SECTION. 

01  ITEM-LIST. 

02  ITEM-PROCESS-NAME. 

03  PIC  S9(4)  COMP  VALUE  15. 

03  PIC  S9(4)  COMP  VALUE  EXTERNAL  JPIS-PRCNAM. 

03  POINTER  VALUE  REFERENCE  PROCESS-NAME. 

03  POINTER  VALUE  REFERENCE  PROCESS -NAME-LENGTH . 

02  TERMINATOR-ENTRY  PIC  S9(9)  COMP  VALUE  ZERO. 
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The  module's  Procedure  Division  is  shown  below. 


PROCEDURE  DIVISION  USING 


APNAME. 
NTM-RETURN 
SS-STATUS . 


START-PROGRAM . 

CALL  "SYSIGETJPI*  USING  BY  VALUE  1,  0.  0, 

BY  REFERENCE  ITEM-LIST, 
BY  VALUE  0.  0.  0 
GIVING  SS-STATUS. 

IF  SS-STATUS  NOT  EQUAL  SS -NORMAL  THEN 
MOVE  CALL-FAIL  TO  NTM-RETURN 
ELSE 

MOVE  PROCESS-NAME  TO  APNAME 

MOVE  CALL-SUCCESSFUL  TO  NTM-RETURN. 


5.2.2  Global  Memory  Routine 

The  global  memory  implementation  on  the  VAX  uses  one 
create  section  module,  CGSHST,  and  a  mapping  module,  MAPHST , 
that  is  called  by  the  MPUs  to  map  to  the  host  global  tables. 

This  implementation  is  unwieldy  because  VMS  COBOL  requires 
manual  page  alignment  of  these  memory  sections.  The  caller  (the 
monitor  for  CGSHST)  of  the  create  section  module  must  have  its 
global  storage  sections  on  page  boundaries.  Unfortunately,  the 
memory  allocation  changes  when  new  data  or  code  is  added  to  the 
MPU  or  monitor.  Readjustments  of  these  sections  may  be  required 
when  these  modifications  are  made.  The  current  technique  for 
managing  this  problem  is  to  use  the  debugger  to  find  the  real 
and  the  mapped  addresses  of  the  section.  If  they  are  different, 
adjustments  to  the  Buffer  areas  surrounding  the  sections  in  the 
MPUINI  Module  of  the  MPU  are  made  until  alignment  is  again 
attained.  For  example,  the  VAX  monitor  AP  creates  the  host 
global  section  which  has  the  following  structure. 
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WORKING-STORAGE  SECTION. 

* 

•  INCLUDE  FILES 

* 

COPY  TBLHST  OF  IISSCLIB. 

COPY  TBLAPC  OF  IISSCLIB. 

HOST  GLOBAL  COPY  TBLLST  OF  IISSCLIB. 

SECTION  COPY  TBLLOG  OF  IISSCLIB. 

COPY  TBLCAT  OF  IISSCLIB. 

COPY  TBLDIR  OF  IISSCLIB. 

COPY  LOGSEL  OF  IISSCLIB. 

01  DUMMY  PIC  X(403). 

01  GLOBAL-END  PIC  X. 

It  calls  CGSHST  to  create  this  section  with  the  CALL: 

CALL  "CGSHST"  USING  IISS-ID, 

DIRECTORY-TABLE , 

HOST-STATUS-TABLE . 

AP -CLUSTER-STATUS-TABLE . 
LINK-STATUS-TABLE , 

LOGON -TABLE. 

MESSAGE-CATEGORY-TABLE . 
LOG-SELECT-STR, 

DUMMY . 

GLOBAL-END. 

RET-STATUS , 

SYSTEM-STATUS 

CGSHST  uses  the  VMS  Systea  Call  "SYS$CRMPSC"  shown  below  to 

create  the 

section. 

CALL  "SYS$CRMPSC"  USING  BY  REFERENCE  IN-ADDRESS 

BY  REFERENCE  OUT-ADDRESS 
BY  VALUE  ACCESS-MODE 
BY  VALUE  524297. 

BY  DESCRIPTOR 

GLOBAL-SEC-NAME. 

BY  REFERENCE  VERS -IDENTIFICATION 
BY  VALUE  RELATIVE-PAGE 
BY  VALUE  CHANNEL 
BY  VALUE 
PAGE -COUNT , 

BY  VALUE  VIRTU AL-BLK-NO 
BY  VALUE  0.  0 
GIVING  SS-STATUS. 
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IN-ADDRESS  and  OUT-ADDRESS  are  the  real  and  mapped 
addresses  and  have  the  structures : 

01  IN-ADDRESS. 

05  IN-ADDR  PIC  S9(9)  COMP 

OCCURS  2  TIMES. 

01  OUT- ADDRESS. 

05  OUT-ADDR  PIC  S9(9)  COMP 

OCCURS  2  TIMES. 

To  check  for  al ignment .  after  the  SYSSCRMPSC  cal  1  has  been 
completed,  IN-ADDR(l)  should  be  compared  to  OUT-ADDR(l).  These 
must  be  the  same.  Then  IN-ADDRC2)  should  be  compared  to 
0UT~ADDR(2).  These  must  be  such  that  the  mapped  address 
(OUT-ADDR(2))  is  in  line  with  the  DUMMY  buffer  of  the  section. 
This  section  created  by  the  Monitor  AP  usually  remains  correctly 
aligned  on  code  modifications. 

Most  of  the  problems  seem  to  appear  in  the  MPU  mapping. 
Each  MPU  has  its  global  sections  defined  in  MPUINI.GOB  as: 


WORKING-STORAGE  SECTION . 


*  INCLUDE  FILES 

*  !  |  M  H  m  |  i  ;  !!!!!!!!  !!  !!  !!  H  H  !!!!!!;'!  I  !  H  H  H  !!  H  !!!  I  !!  H  !  M  !  H  ! 

*  *  *  PLEASE  LEAVE  THESE  WHERE  THEY  ARE  —  AT  TOP  OF  WORKING  STG  ! • • 

*  M  !  M  H  !  M  !!!!  I  !!  M  !!!!!!!!!!!!!!!  I  !>!!  I!  <!!!!!  M  M  !!  M  !>!  M  !  H  !  < 

01  GLOBAL-PAGE-BOUNDRY  PIC  X(104). 

* 

COPY  TBLHST  OF  IISSCLIB. 

COPY  TBLAPC  OF  IISSCLIB. 

COPY  TBLLST  OF  IISSCLIB. 

COPY  TBLLOG  OF  IISSCLIB. 

COPY  TBLCAT  OF  IISSCLIB. 

COPY  TBLDIR  OF  IISSCLIB. 

COPY  LOGSEL  OF  IISSCLIB. 

COPY  HSTGLE  OF  IISSCLIB. 

•  ••••»•••*  ejjd  Qp  HOST  GLOBAL  MEMORY* ******* v *******************  * 

• 

*»  M  !  f  !!  M  !  f  !!  M!  !!!  !!  H  !!!  M!  M  !!»  H!  HI  !!«  m  !!»!!!  M  !!!!!  M  !  I  !  ! 

The  MPU's  mapping  call  is  the  "map  section"  KAPHST  call  shown 
below. 
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CALL  "MAPHST"  USING  HOST-STATUS-TABLE 

AP-CLUSTER-STATUS-TABLE 

LINK-STATUS-TABLE 

LOGON-TABLE 

MESSAGE -CATEGORY -TABLE 

HOST-BUFFER 

HOST-GLOBAL-END 

RET-OODE 

SS -STATUS. 


The  MAPHST  routine  uses  the  VMS  service  "SYSIMGBLSC"  to  map  to  an 
existing  section 

CALL  "SYSSMGBLSC"  USING  BY  REFERENCE  IN-ADDRESS 

BY  REFERENCE  OUT-ADDRESS 
BY  VALUE  ACCESS -MODE 
BY  VALUE  000008, 

BY  DESCRIPTOR 

GLOBAL-SEC-NAME . 

BY  REFERENCE  VERS-IDENTIFICATION 
BY  VALUE  RELATIVE-PAGE 
GIVING  SS-STATUS. 

To  complete  the  alignment  check,  the  IN-ADDRESS  and 
OUT-ADDRESS  elements  should  be  examined  after  the  "SYSSMGBLSC" 
call.  If  IN-ADDR(l)  and  OUT-ADDR(l)  are  not  the  same,  APC--8UFFER 
should  be  adjusted  so  that  HOST-STATUS -TABLE  is  on  a  page  boundary. 
Again,  OUT-ADDR(l)  is  a  page  boundary  so  adjustments  must  be  made 
to  this  address  or  one  512KB  from  it.  The  checks  on  IM-ADDR(2) 
against  OUT-ADDR(2)  should  ensure  that  OUT-ADDR(2)  is  within  the 
buffer  zone  at  the  end  of  each  section. 

5. 2. 2. 2  CGSHST 

The  logic  of  CGSHST  consists  of  a  call  to  "GGSHST"  by  the 
monitor  to  create  the  host  global  seotion  that  is  shared  by  the 
monitor  and  all  the  MPUs  of  that  host.  It  contains  IISS  operating 
status  information  and  is  written  to  only  by  the  monitor  AP.  The 
global  section  is  created  with  the  VAX  "oreate  global"  system  call. 
"SYSSCRMPSC" .  The  call  requires  the  addresses  of  the  beginning  and 
end  of  the  seotion.  The  addresses  are  obtained  from  an  Assembler 
Program  (ADDRESS. MAR)  that  is  oalled  twioe: 

CALL  "ITMADR"  USING  AP-CHAR-TABLE 

GIVING  GLOBAL- BEG1N-ADDR 
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CALL  “ ITMADR"  USING  GLOBAL-END 

GIVING  GLOBAL -END- ADDR 


The  assembler  routine  consists  of  the  following  statements: 

ITEMADR: :  .WORD  0 

MOVL  4(AP) ,R0 
RET 
.END 

The  arguments  of  the  VAX  "SYSSCRMPSC"  call  are  described  in 
the  VMS  System  Services  Manual  [5]. 

The  call  argument  values  are  in  the  include  file.  HSTGLD.INC.  The 
routine  initialises  the  tables  of  the  global  section  with 
statements  that  are  in  INTHST.INC. 

5. 2. 2. 3  MAPHST 

MAPHST  is  the  module  called  by  the  MPUs  to  map  to  the  host 
global  tables.  The  MPU  CALL  to  MAPHST  (Section  4.2.2)  provides  the 
structure  that  is  being  mapped  to  the  host  section.  Like  CGSAPC 
and  CGSHST ,  this  routine  uses  the  ITMADR  entry  (Section  4.2.2. 1)  to 
determine  the  beginning  and  ending  addresses  of  this  section.  It 
then  calls  "SYSSMGBLSC*  (Section  4.2.2)  whose  argument  values  are 
in  the  WORKING  STORAGE  SECTION  of  the  module.  It  returns  the 
call's  status  to  the  calling  MPU  in  SS-STATUS. 

5.2.3  System  Time  Routines 

5.2.3. 1  ASCTIM 

ASCTIM  is  the  routine  called  by  the  MPUs  for  the  ASCII  system 
time.  The  module  first  uses  the  VMS  call,  "SYSSGETTIM,  to  get  the 
system  time  as  a  binary  string  and  then  oalls  "SYS® ASCTIM"  to 
4  convert  this  string  to  ASCII.  The  ASCII  string  is  returned  as  a 

twenty  three  character  string  to  the  calling  MPU. 

9. 2. 3. 2  OETTIM 

IGETTIM  oalls  the  VMS  routine  aSYSSGETTIMa  as  indicated  below 
to  get  the  system  time  in  binary. 
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PROCEDURE  DIVISION  USING  TIME- VALUE. 

NTM-RETURN, 
SS-STATUS . 

START-PROGRAM . 


JUST  GET  THE  TIME.  SET  NTM  RETURN  CODE  AND  RETURN 

CALL  "SYSSGETTIM"  USING  TIME-VALUE 

GIVING  SS-STATUS. 
IF  SS-STATUS  -  SS -NORMAL 

MOVE  CALL- SUCCESSFUL  TO  NTM-RETURN 

ELSE 

MOVE  CALL-FAILURE  TO  NTM-RETURN. 

EXIT-PROGRAM. 

EXIT  PROGRAM. 
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APPENDIX  A 

TERNS  AND  ABBREVIATIONS 


Here  is  the  list  of  symbols,  abbreviations,  and  acronyms 
used  in  this  report. 

AP  Application  Process 

APC  Application  Process  Cluster 

API  Application  Process  Interface 

CDMRP  Common  Data  Model  Request  Processor 

COMM  Communications  Handler 

CPC I  Computer  Program  Configuration  Item 

DBMS  Data  Base  Management  System 

DML  Data  Manipulation  Language 

ICAM  Integrated  Computer  Aided  Manufacturing 

IDSS  Integrated  Decision  Support  System 

IISS  Integrated  Information  Support  System 

I PC  Inter  Process  Communication 

LAN  Local  Area  Network 

MCMM  Manufacturing  Control  Material  Management 

MDL  Message  Definition  Language 

MM  Message  Manager 

MO  Maintain  Operability 

MPU  Message  Processing  Unit 

MRP  Materials  Requirements  Planning 

MSG  Message 

NTM  Network  Transaction  Manager 

OS  Operating  System 

PM  Process  Manager 

QA  Quality  Assurance 

SS  System  Specification 

Ul  User  Interface 

VAX  Trademark  of  Digital  Equipment  Corporation:  32  bit 

minicomputer 

VMS  Trademark  of  Digital  Equipment  Corporation:  The  VAX  OS 

Thi 6  paragraph  contains  definitions  of  IISS  related  terms  and 
general  computer  terms  that  are  used  in  this  document. 


AP 


See  Application  Prooess. 


Abnormal 

Termination 


Stoppage  of  a  prooess  prior  to  its  normal 
completion.  (Abort) 


Termination 


(Abort) 


A-l 
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Alive  AP 


Application 

Process 


Appl i cat ion 
Process  Cluster 


Authorization 

Awake  AP 

Backlog 

CDMRP 

COMM 

Clean  Point 

Cluster 
Common  Data 

Common  Data  Model 


Common  Data  Model 


An  application  process  that  is  capable  of 
being  initiated. 

Within  the  ZISS  Architecture;  a  cohesive 
unit  of  software  that  can  be  initiated  as  a 
unit  to  perform  some  function  or  functions. 
See  also:  Process. 

A  logically  related  group  of  applicatio 
processed  that  resides  on  a  single  host 
system.  The  application  processes  are 
collected  at  a  single  cluster  because  of 
their  common  need  to  aooess  the  same 
database.  (In  previous  MTM  documents  this 
conoept  was  referred  to  as  “Workstation”). 

A  relationship  between  message  type  and 
legal. paths  of  messages  conforming  to  that 
type. 

An  application  prooess  that  is  currently 
executing. 

Messages  waiting,  in  a  queue,  to  be 
processed. 

See  Common  Data  Model  Request  Processor. 

See  Communications  Handler. 

A  baseline  of  the  entire  system  state  at  a 
given  point  in  time  so  that  recovery  is 
possible  from  that  point. 

See  Application  Prooess  Cluster. 

Information  that  may  be  shared  among  users 
and  is  subject  to  policies  and  procedures 
of  the  IISS. 

A  description  of  the  data,  its  structure, 
allowable  (CDM)  operations,  and  Integrity 
constraints  for  data  of  common  interest 
within  the  II8S. 

The  implementation  of  the  CDM  within  the 
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Request  Processor 

IISS.  The  current  design  6peoifies  the  use 
of  extremities. 

Communications 

Handler 

An  IISS  Configuration  Item  that  servioes 
IISS  network  communications.  It  aooepts 
messages  from  the  MTM  for  off-host 
destinations.  It  provides  MTM  with 
messages  from  off-host  sources. 

DBMS 

See  Data  Base  Management  System. 

DHL 

See  Data  Mem i pul at ion  Language. 

Database 

A  collection  of  logically  related  data 
managed  by  a  DBMS. 

Data  Base 

Management  System 

A  computerised  system  consisting  of 
numerous  components,  which  have  as  their 
collective  purpose  the  implementation, 
management,  and  protection  of  large-scale 
data  bases. 

Data  Manipulation 
Language 

A  formal  language  for  specifying  data 
storage,  modification,  and  retrieval 
functions  under  a  DBMS. 

Destination 

An  application  process  (which  may  be  user 
role)  to  which  a  message  is  sent. 

Heterogeneous 

Composed  of  parts  of  different  kinds; 
having  widely  dissimilar  elements  or 
constituents . 

Homogeneous 

Composed  of  parts  all  of  the  same  kind. 

Host 

See  Host  Maobine. 

Host  Machine 

A  configuration  of  a  prooessor(s)  and 
associated  peripherals. 

IISS  Component 

Application  Processes  involved  in  IISS 
support  activities.  See;  CDMRP,  UI,  COMM . 

I IBS  Operation 

Messages 

Messages  entered  directly  to  the  MTM  by  an 
operator.  These  inolude:  start-up, 
shut-down,  restart,  and  provide  status  and 
statistics . 
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IZSS  Shut-down 

IISS  Start-up 
Integrated  AP 

Initiation  Message 

LAM 

Load 

MDL 

MM 

Maintain 
Opcrabi 1 ity 

Message 

Message  and  Error 
Log 

Message  Category 

Messages  froe 

Off-Cluster 


A  signal  or  IISS  operator  command  that 
initiates  the  orderly  shut-down  of  the 
entire  IISS  system  or  an  individual 
workstation. 

A  signal  or  IISS  operator  command  that 
initiates  the  IISS  on  a  single  host. 

An  application  prooess  designed  and  written 
in  accordance  with  the  IISS  Integration 
rules . 

A  message  that  specifically  requires  the 
initiation  of  an  application  prooess.  The 
message  may  also  carry  data  for  that 
prooess . 

Local  Area  Network. 

To  bring  a  bound  Clinked)  6et  of  computer 
instructions  into  a  computer  memory  unit  in 
preparation  for  its  execution  as  a  process. 

Message  Definition  Language.  Neutral  syntax 
and  semantics  for  formatting  IISS  messages. 

See  Message  Manager. 

The  name  given  to  that  part  of  the  MTM  that 
will  facilitate  system  wide  services  of 
restart,  recovery,  shut-down,  and  system 
6tatus  monitoring  and  recording. 

A  structured  unit  of  information. 

The  record  of  messages  (legal  and 
erroneous)  that  are  processed  by  the 
message  manager. 

A  group  of  message  types  sharing  common 
processing  requirements. 

Any  message  that  has  as  its  souroe  an  AP  or 
NTH  that  is  not  resident  on  the  duster  in 
question. 
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Message  froa 
On -Cluster 


Message. 

Definition 


Message  Manager 


Message  to  IISS 
Operator 


Messages  to 
Off-Cluster 


Message  to 
On-Cluster 

Message  to  be 
Routed 

Message  Type 
MO 

MO  Data  and  Status 
Messages 

Native  Mode 

Network 

Non- integrated  AP 
NTM 


Any  aessage  sent  by  a  local  AP  that  is 
direoted  to  another  on  APC  AP  or  to  another 
NTM  (i.e..  requiring  the  routing  services 
of  the  Message  Manager). 

The  legal  (recognised  and  allowed)  values 
to  which  a  aessage  aust  oonfora  to  be 
acoepted  for  processing  at  an  AP  on  a  given 
APC  on  a  given  host. 

The  naae  given  to  the  part  of  the  NTM  that 
will  provide  the  service  for  the  identified 
Manage  Message  functions. 

Typically  a  response  to  an  operation 
request.  This  aessage  could  also  be  a 
request  for  operator  action. 

Any  aessage  that  has  as  its  source  an  AP  or 
NTM  that  is  not  resident  on  the  cluster  in 
question. 

Messages  directed  to  an  AP  (resident  on  the 
cluster)  that  contain  lnforaation  necessary 
for  the  prooess  to  perfora. 

A  aessage  that  has  another  AP  as  its 
destination. 

The  identification  of  the  nature  of  a  given 
aessage . 

See  Maintain  Operability. 

Any  aessage  direoted  to  the  aaintain 
operability  function. 

Character  code  native  to  a  particular 
aachine,  either  ASCII  or  EBCDIC. 

Several  coaputers  and  a  corauni cat ions 
facility  connecting  then. 

An  Application  Process  designed  without 
adherenoe  to  the  IISS  Integration  rules. 

Network  Transaction  Manager.  That  portion 
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OS 

OS  Process  Control 
Response 

OS  Process  Control 
Request 

On-APC  AP  Messages 

Operabi 1 ity 
Messages 

Operating  Systen 

Priority 

Process 

Process  Manager 

Prooess  Mane 
Requl resent 


of  the  IISS  that  n&nages  nessages  and 
application  processes  and  naintains  the 
operability  of  the  IISS. 

See  Operating  Systen. 

Response  fron  the  host  operating  systen  to 
a  request  for  servioes,  (i.e.,  process  ID 
assigned,  process  exists,  process  does  not 
exist) . 

Request  for  servioes  to  be  provided  by  the 
host  operating  systen. 

Any  nessage  that  has  as  its  destination  an 
AP  that  is  resident  on  the  workstation  in 
question. 

Messages  Initiated  by  Maintain  Operability 
to  handle  an  IISS  operation  request  and  to 
non i tor  the  IISS  systen. 

Software  that  controls  the  execution  of 
conputer  prograns  and  that  nay  provide 
scheduling,  debugging,  input-output 
control,  accounting,  oonpilation,  storage 
assignnent,  data  nanagenent,  and  related 
overall  systen  nanagenent. 

The  expectation  of  processing  urgency 
assigned  to  a  nessage  type.  The  recognized 
transaction  priorities  are:  standard, 
innediate  and  tine-triggered. 

The  basic  unit  of  work  fron  the  standpoint 
of  the  conputer 's  operating  systen. 

The  nane  given  to  the  part  of  the  NTM  that 
will  provide  the  service  for  the  identified 
Manage  Processes  function.  (See  DS/A2 , 
Section  10.2) 

The  AP  Hane  and  instanoe  identifier  of  an 
initiated  AP. 

Stated  functions  for  infornatlon  processing 
fluid  associated  constraints. 
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Resources 

Source 

Status  and 
Statistics  Log 

System 

Task 
Test  Bed 

UI 

Update 

User 


User  Application 
Process 

User  Interface 

View 


People,  hardware,  software,  and  other 
components  used  to  prooess  information. 

An  Application  Process  from  whioh  a  message 
is  sent. 

Data  regarding  the  AP  status,  resource 
utilisation,  message  traffic  provided  in 
response  to  an  operation  request. 

A  collection  of  people,  hardware,  software 
and  methods  organised  to  accomplish  a  set 
of  specific  functions. 

See  Process. 

A  collection  of  computer  hardware, 
software,  storage  devioes,  and  other 
peripherals  used  for  testing  application 
software  and  system  ooncept6.  Usually  not 
the  target  operational  system. 

See  User  Interface. 

The  process  of  changing  values  in  all  or 
selected  entries,  groups,  or  data  items 
stored  in  a  database  or  adding  or  deleting 
data  occurrences. 

Human  being  who  requests  processing  to  be 
done.  The  person  entering  a  transaction  at 
a  terminal.  The  user  can  also  be  a 
non-human  that  performs  these  functions  but 
this  term  will  not  be  used  in  this  sense  in 
this  specification. 

Any  application  process  not  involved  in 
IISS  support  activities. 

An  application  process  that  manages  the 
user-terminal  Interface. 

That  whioh  is  within  the  range  of  vision. 
Also,  that  data  whioh  is  of  interest  to  a 
specific  application  process. 
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APPENDIX  B 
NTM  DOCUMENTATION 


This  document  is  Intended  to  provide  information  on  the 
internals  of  the  NTM.  However,  the  information  presented 
represents  only  the  tip  of  the  proverbial  iceberg.  Further 
details  are  to  be  found  in  the  following: 


[1]  SofTech,  Inc.,  "IISS  Test  Bed  Network  Transaction  Manager 
Development  Specification,*  June  1983.  (Updated  March 
1984). 

This  document  provides  the  functional  description  of  the 
NTM  components.  It  includes  a  data  dictionary  of  data 
items  used  by  the  NTM  along  with  a  full  description  of 
each  of  the  internal  message  types . 


[2]  SofTech,  Inc.,  “IISS  Test  Bed  Network  Transaction  Manager 
Product  Specification,*  June  1983. 

Published  in  three  volumes,  this  document  contains  the 
structure  charts  and  module  descriptions  of  the  NTM  code 
*As-Built.‘  VolumeM  covers  the  Monitor  AP;  Volume  2 
covers  the  Message  Processing  Unit;  and  Volume  3  contains 
the  NTM  services.  System  Dependent  Code,  and  Table 
Handling  Routines. 


[3]  SofTech,  Inc.,  “IISS  Test  Bed  Network  Transaction  Manager 
Operator's  Manual  (Release  1.2),“  March  1984. 

This  document  is  intended  for  use  by  the  IISS  Operator. 

It  includes  descriptions  of  the  Operator  Commands  and  IISS 
error  codes  along  with  guidelines  for  table  maintenance 
and  troubleshooting  suggestions. 


[4]  SofTech.  Inc.,  "IISS  Test  Bed  IISS  Programmer's  Guide, 
Revision  C . *  March  1984. 

This  document  is  intended  for  use  by  Application 
developers  writing  AP's  that  will  run  in  the  IISS 
environment.  It  contains  full  descriptions  of  the  system 
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services  including  calling  parameters,  inputs,  outputs, 
and  return  code  values.  Examples  are  provided  along  with 
suggestions  for  use. 


[5]  Digital  Equipment  Corporation;  “VAX/ VMS  System  Services 
Referenoe  Manual  * ;  Maroh  1980 . 


U  S  Government  Printing  Office:  1987  —  748-061/60907 


B-2 


